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Preface 


The  STARS  Structured  Specification  for  the  DoD  Advanced  Automation  System  which  shall  also  be  referred 
to  as  the  DoD  Advanced  Automation  System  Information  Object  Model  is  the  Required  IBM  Deliverable  for 
STARS  Task  IQM15,  Phase  II.  This  document  serves  as  an  example  of: 

•  IOM  Packaging  Concepts, 

•  Application  of  the  IOM  layered  modeling  techniques  and 

•  IOM  Object  decomposition,  learned,  practiced  and  refined  during  IQM15  phases  I  and  II. 

This  document  is  not  intended  to  be  a  tutorial  on  the  IOM  Methodology;  it  is  an  example  of  its  applica¬ 
tion.  A  paper  will  be  be  prepared  for  STARS  Task  IQM15  Phase  III  which  will  discuss  the  IOM  method¬ 
ology  and  serve  as  a  companion  document  to  understand  the  techniques  employed  in  the  preparation  of  this 
deliverable. 

This  document  should  not  be  viewed  as  an  official  document  in  its  descriptions  of  a  proposed  DoD 
Advanced  Automation  System.  Although  our  original  intent  for  IQM15  phase  II  was  to  faithfully  apply  the 
methodology  as  learned  during  IQM15  phase  I  and  concentrate  on  extensive  information  capture,  this  was 
not  possible.  The  IOM  methodology,  as  practiced  by  Foxboro,  was  not  completely  conveyed  during  JQM15 
phase  I  and  there  was  no  reference  material  available  which  explained  IOM  modeling  function  (how  to  apply 
the  methodology)  and  IOM  modeling  form  (what  things  should  look  like  after  the  methodology  has  been 
applied).  IQM15  phase  II  became  a  discovery  process,  where  we  modeled  several  versions  of  a  DoD  AAS  in 
our  process  of  learning  Foxboro's  techniques,  as  well  as  refining  them.  This  document  represents  work  per¬ 
formed  over  a  forty-five  (45)  day  period  during  QM15  phase  II,  where  the  IBM  team  applied  the  method¬ 
ology,  from  insights  gained  through  interactions  with  Foxboro  personnel.  Further,  several  of  the  QM15 
team  members  spent  time  in  the  months  of  January  and  February,  1990  to  populate  their  sections  of 
Excelerator  database  and  document  their  IOM  models. 

In  the  IOM  development  process,  several  versions  are  prepared  during  the  90  to  120  day  analysis  period. 

The  first  version  of  the  IOM  is  referred  to  as  the  "first  pass  book."  This  version  is  to  be  reviewed  and 
critiqued  by  domain  experts  who  generate  issues  and  problems  that  need  to  be  addressed  in  the  "second  pass 
book."  Typically  only  two  books  are  required,  but  a  third  can  be  produced,  if  the  IOM  is  not  sufficiently 
complete.  This  product  represents  a  "first  pass  book."  The  'first  pass  book"  may  or  may  not  be  complete, 
but  has  sufficient  material  in  it  to  conduct  a  technical  review  for  material  validation  with  domain  experts. 

Although  this  IOM  is  not  complete,  it  does  serve  as  a  good  example  of  the  form  of  an  IOM.  The  most 
illustrative  example  of  the  IOM  layered  modeling  technique  (also  referred  to  as  the  White  Layered  Model)  is 
the  Information  Object  Model  for  1.0  Traffic  Surveillance.  The  most  complete  example  Information  Object 
Models  in  the  document  are  6.0  Flight  Plan  Entry  Support  and  7.0  Flight  Plan  Operation  Support. 
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Abstract 


The  DoD  Advanced  Automation  System  Information  Object  Model  is  a  deliverable  from  IBM  STARS  Task 
IQM15,  Phase  II.  This  document  serves  as  an  example  of  1)  IOM  Packaging  Concepts,  2)  Application  of 
the  IOM  layered  modeling  techniques  and  3)  IOM  Object  decomposition,  learned,  practiced  and  refined 
during  IQM15  phases  I  and  II.  This  document  is  not  intended  to  be  a  tutorial  on  the  IOM  Methodology; 
it  is  an  example  of  its  application.  A  paper  will  be  be  prepared  for  STARS  Task  IQM15  Phase  III  which 
will  discuss  the  IOM'  methodology  and  serve  as  a  companion  document  to  understand  the  techniques 
employed  in  the  preparation  of  this  deliverable. 

An  Information  Object  Model  is  a  specification  for  a  proposed  system,  that  1)  describes  the  context  for  a 
system,  2)  describes  the  major  functional  objects  of  that  system  and  how  they  relate  to  each  other  by  the 
information  they  share  and  3)  provides  a  description  of  the  major  functional  objects  of  the  system,  using 
extensions  to  real-time  structured  analysis,  referred  to  as  the  Foxboro  Methodology  in  this  document.  Pre¬ 
paring  an  IOM  for  a  project  involves  the  interviewing  of  domain  experts,  as  well  as  documentation  review. 
Information  from  interviews  are  recorded  in  a  CASE  tool  for  diagram  generation.  The  diagrams  generated 
from  the  CASE  tool  are  used  as  a  communication  vehicle  to  validate  and  refine  the  model  data  stored  in  the 
CASE  tool  database. 

STARS  was  interested  in  the  Information  Object  Model' specification  process  as  a  means  for  developing  a 
complex  specification  in  a  short  time  period  of  90  to  120  days.  The  90  to  120  day  period  of  performance 
assumes  that  the  team  to  build  the  IOM  is  fully  trained  in  the  methodology  and  associated  tools  before  the 
beginning  of  the  modeling  effort.  One  of  the  goals  of  QM15  was  to  explore  the  use  of  the  IOM  product  as  a 
means  to  initiate  a  concurrent  software  development  life  cycle.  Another  goal  was  to  examine  the  potential 
role  of  the  IOM  in  the  procurement  process.  An  IOM  might  be  prepared  for  a  new  DoD  program,  giving 
the  DoD  program  manager- a  better  understanding  of  the  program  he  or  she  must  manage. 
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Introduction 


The  DoD  Advanced  Automation  System  Information  Object  Model  is  the  required  deliverable  for  IBM 
STARS  Task  QM15,  Phase  II.  This  report  is  the  result  of  the  second  phase  of  STARS  QM15,  where  the 
three  STARS  prime  contractors  developed  Information  Object  Models  of  their  selected  applications.  ISM 
initially  selected  Military  Air  Traffic  Control  as  its  application.  Our  approach  was  to  build  a  model  of  a 
generic  military  air  traffic  control  system  in  the  first  part  of  phase  II,  and  to  specialize  this  model  with  a 
selected  military  air  traffic  control  operation.  After  the  QM15  mid-point  review,  IBM  was  directed  by  the, 
government  to  redirect  its  modeling  efforts  to  develop  a  DoD  Advanced  Automation  System  Information 
Object  Model.  Thus,  IBM  conducted  two  semi-related  efforts  in  Phase  II,  namely:  1)  building  an  IOM  of 
a  generic  military  air  traffic  control  system  and  2)  building  an  IOM  of  the  DoD  AAS.  Both  of  these  applica¬ 
tions  certainly  contained  similar  functionality,  but  addressed  the  problem  of  air  traffic  control  with  dramat¬ 
ically  differing  sets  of  requirements.  Building  the  DoD  AAS  IOM  meant  the  IBM  team  had  to  start  their 
modeling  efforts  in  the  second  period  of  phase  II  from  scratch. 

In  one  of  our  reviews  with  Foxboro  consultant,  Dr.  Gerald  White,  IBM  illustrated  some  problems  in  func¬ 
tional  object  decomposition  that  enabled  Dr.  White  to  recognize  that  there  was  a  problem  in  the  way  we 
were  modeling  and  decomposing  our  objects.  Dr.  White  soon  discovered  that  all  three  primes  were  uni¬ 
forming  applying  what  they  had  learned  during  phase  I,  although  these  practices  were  different  than  he 
intended.  Because  the  major  goal  of  QM15  was  to  produce  an  Information  Object  Model  which  was  illus¬ 
trative  of  the  way  Foxboro  applied  their  methodology,  we  felt  we  should  significantly  revise  our  IOM. 

Hence,  three  weeks  before  the  QM15  phase  II  final  review,  the  IBM  team  rewrote  its  existing  IOM  to 
empioy  the  modeling  heuristics  we  were  able  to  leam  from  Dr.  White.  IBM  refined  these  modeling 
heuristics  and  presented  them  at  the  final  phase  II  review  meeting  in  the  presentation  entitled  IOM  Method¬ 
ology  Notes.  Due  to  the  course  of  our  phase  II  effort,  IBM  required  time  in  IQM15  phase  III  to  complete 
portions  of  our  IOM  deliverable. 

Although  our  DoD  AAS  IOM  is  not  complete,  it  does  illustrate  the  transformation  modeling  techniques  as 
applied  by  Foxboro.  Foxboro,  currently,  does  not  have  a  public-domain  IOM  available  which  illustrates 
these  techniques.  The  IBM  DoD  AAS  IOM  is  a  representative  example  available  of  the  application  of 
Foxboro 's  techniques  for  building  an  IOM,  which  employs  Foxboro's  packaging  ideas  along  with  some  IBM 
enhancements  in  presentation,  real-time  structured  analysis  and  Foxboro's  undocumented  methodology  for 
transformation  modeling.  We  feel  this  is  our  contribution  to  STARS  task  QM15  and  the  STARS  program. 

In  the  following  sections,  we  will  discuss  requirements  for  a  DoD  AAS,  discuss  the  relationship  between 
DoD  AAS  and  FAA  AAS,  describe  their  similarities  and  differences,  discuss  criteria  for  scoping  the  task  for 
producing  the  DoD  AAS  IOM  and  identify  the  criteria  selected  for  building  the  DoD  AAS  IOM. 


DoD  Advanced  Automation  System  Requirements 

The  DoD  Advanced  Automation  System  to  support  military  air  traffic  control  in  the  future  is  mandated  to 
make  use  of  existing  FAA  capabilities  where  ever  it  is  possible,  and  to  augment  those  capabilities  to  meet 
specific  military  needs.  To  support  military  air  traffic  control  requirements  will  r  ;quire  enhancements  to 
FAA  capabilities  including. 

•  Added  surveillance  capabilities 

•  Enhanced  tracking  capabilities 

•  Added  approach  control  system  support 

•  Added  ground-based  interrogation  system  support,  including  support  for  modes:  2,  3,  4,  C  and  S 

•  Automation  of  standard  voice  recording 
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‘  Enhanced  tower  night  operations  support 

«  The  ability  to  conduct  tower  and  approach  control  in  a  stand-alone  mode  of  operation,  when  FAA 
system  support  is  unavailable. 


Do D  Advanced  Automation  System  Components 

The  DoD  Advanced  Automation  System  is  composed  of: 

•  The  FAA  Advanced  Automation  System 

•  Stand-alone  Tower/Terminal  Remote  TRACON  Facilities  (T/RT). 

The  FAA  Advanced  Automation  System  is  composed  of: 

•  Area  Control  Facilities  (ACF)  to  be  supported  by  the  Area  Control  Computer  Complex  (ACCC) 

•  Enroute  Control  Centers,  supported  by  the  ACCC 

•  Terminal  Remote  Approach  Control  Facilities  (TRACON),  supported  by  ACCC  equipment  called  Ter¬ 
minal  Advanced  Automation  System  (TAAS) 

•  Tower  Control  Centers,  supported  by  the  Tower  Control  Computer  Complex  (TCCC). 

Currently  the,  FAA-plarmed  T/P.T  depends  on  Area  Enroute  Control  for: 

•  Real-time  weather  data  processing 

•  Flight  plan  route  processing 

•  Strategic  prediction  functions 

•  Long-term  recording 

•  Training  scenario  generation 

•  Software  release  and  adaptation  data  downloading. 

These  capabilities  must  be  included  in  the  DoD  AAS  T/RT  to  permit  stand-alone  operations. 


Modeling  Approach 

The  goal  of  IBM  STARS  task  QM15  was  to  model  the  essential  processing  requirements  for  a  DoD 
Advanced  Automation  System.  The  DoD  Advanced  Automation  System  Information  Object  Model  is  a 
specification  model  describing  'what"  the  DoD  AAS  is  and  what  it  should  do. 

The  IBM  STARS  task  QM15  modeling  approach  to  meet  the  above  goals  was  to: 

•  Identify  the  differences  between  DoD  AAS  AND  FAA  AAS 

•  Identify  any  differences  in  the  essential  functionality 

•  Identify  specific  constraint  requirements  that  need  to  be  addressed  in  the  implementation  model 
'  Determine  the  essential  processing  characteristics  of  the  DoD  AAS 

•  Model  an  10 M  representing  the  essential  processing  characteristics  of  the  DoD  AAS. 
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Examination  of  Basic  Essential  Processing  Differences 

The  purpose  of  both  DoD  AAS  and  FAA  AAS  is  to  perform  air  traffic  control.  Essential  processing  differ¬ 
ences  do  not  exist,  as  they  both  address  the  same  problems: 

•  Both  have  requirements  for  traffic  and  weather  surveillance 

•  Both  have  requirements  for  tactical  traffic  prediction  and  strategic  traffic  prediction 

•  Both  have  requirements  for  approach  control  systems  support. 

IBM  STARS  made  the  decision  to  model  DoD  AAS,  using  FAA  AAS  as  the  basic  model.  It  was  our  intent 
to  address  the  DoD  AAS  constraint  requirements  in  the  DoD  AAS  Implementation  Modeling  phase; 
however,  due  the  redirection  of  STARS,  this  effort  is  currently  not  planned. 

Determining  the  Scope  of  Modeling  Activities 

FAA  AAS  is  composed  of  23  Area  Control  Facilities  which  includes: 

•  1  Enroute  Center  per  Area  Control 

•  Multiple  Approach  Control  Facilities  per  Area  Control 

•  Multiple  Tower  Control  Facilities  per  Approach  Control. 

Enroute  Center  and  Approach  Control  facilities  are  identical  in  the  processing  that  they  must  perform. 

Tower  Control  facilities  perform  a  subset  of  the  processing  that  an  Enroute  Center  and  Approach  Control 
Facilities  perform,  as  well  as  functions  unique  to  the  tower. 

The  processing  required  by  the  DoD  AAS  for  the  Remote  TRACON  Portion  of  a  T/RT  is  addressed  in  the 
Area  Control  IOM.  The  processing  required  by  the  DoD  AAS  for  the  Tower  Control  Portion  of  a  T/RT 
will  be  addressed  in  the  Tower  Control  IOM.  (NOTE:  Modeling  of  the  Tower  Control  IOM  was  to  be  a 
follow-on  activity  to  be  done  in  conjunction  with  an  IOM  completion/implementation  Modeling  activity, 
and  is  not  addressed  in  the  Phase  II  DoD  AAS  IOM.) 

The  following  DoD  AAS  requirements  represent  implementation  issues  to  be  addressed  in  the  Implementa¬ 
tion  Modeling  phase,  namely: 

•  Added  surveillance  capabilities  --  SURVEILLANCE 

•  Enhanced  tracking  capabilities  -  FLIGHT  PLAN  AND  TRACKING  ANALYSIS 

•  Added  approach  control  system  support  —  TOWER  CONTROL 

•  Added  ground-based  interrogation  system  support  for  ro  jdes  2,  3,  4,  C  and  S  —  SURVEILLANCE 

•  Automation  of  standard  voice  recording  --  RECORDING  SUPPORT 

•  Enhanced  tower  night  operations  support  -  TOWER  CONTROL. 

Modeling  Scope  for  the  DoD  AAS  Model 

The  DoD  AAS  Model  requires  two  IOMs:  One  for  Area  Control  and  one  for  Tower  Control.  Due  to  the 
limitation  of  time  and  resources,  and  our  re-direction  from  military  air  traffic  control  to  DoD  AAS,  IBM 
STARS  Task  QM15  concentrated  its  efforts  on  modeling  the  Area  Control  IOM.  The  Tower  Control  IOM 
and  the  DoD  AAS  Implementation  Model  were  to  be  addressed  in  future  phases,  however,  based  on  cus¬ 
tomer  re-direction  of  STARS,  these  efforts  are  not  currently  planned. 
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Mission  Statement  for  the  DoD  Advanced  Automation  System 

The  proposed  mission  of  a  DoD  Advanced  Automation  System  is  to  provide  automated  support  for  opera¬ 
tional  Military  Air  Traffic  Control.  DoD  Advanced  Automation  System  shall  use  existing  FAA  system 
capabilities  and  be  able  to  operate  autonomously. 

The  area  control  for  the  DoD  Advanced  Automation  System  will  monitor  and  control  an  area  of  defined  air 
space.  Tower  control  for  the  DoD  Advanced  Automation  System  will  control  airport  ground  operations. 
The  DoD  Advanced  Automation  System  will  provide  for  the  safe  and  timely  departure  and  arrival  of  mili¬ 
tary  controlled  flights. 

System  flow  control  shall  be  aided  from  both  the  FAA  national  flow  controller  and  the  FAA  and  DoD  area 
flow  controllers.  They  will  provide  military  controllers  with  airspace  traffic  advisories  and  recommendations 
on  areas  of  congestion  to  avoid,  for  managing  military  flight  operations. 

The  DoD  Advanced  Automation  System  will  provide  monitoring  of  aircraft  positions  in  relation  to  other 
aircraft  traffic,  terrain  and  weather  conditions  within  a  defined  air  space.  The  system  will  also  support  the 
management  and  control  of  special  use  airspace,  as  required.  The  system  surveillance  capability  shall  include 
primary  target  identification  and  secondary  target  identification,  supported  by  ground  based  interrogation 
systems.  Weather  surveillance  shall  be  supported  by  the  primary  surveillance  systems,  augmented  by  weather 
surveillance  systems.  Further,  the  DoD  Advanced  Automation  System  will  provide  strategic  and  tactical 
prediction  capabilities  for  performing  air  space  collision  situation  assessment  to  identify  short-term  and  mid¬ 
term  situations  for  Military  Air  Traffic  Control  personnel  to  assess  and  act  upon. 

Area  Control  for  the  DoD  Advanced  Automation  System  will  provide  the  functionality  included  for  both  an 
FAA  Enroute  Center  and  a  Terminal  Remote  Approach  Control  (TRACON).  The  Area  Control  for  the 
system  will  provide: 

•  for  the  sequencing  and  separation  of  aircraft; 

•  navigation  instructions  to  avoid  identified  situations  (e.g.  aircraft-to-aircraft  traffic  conflicts,  aircraft- 
terrain  conflicts,  hazardous  weather,  terrain  obstacles,  etc.-); 

•  for  the  tracking  of  controlled  aircraft  against  filed  flight  plans; 

•  navigation  instructions  to  aircraft  as  requested. 

Tower  Control  for  the  DoD  Advanced  Automation  System  will  include  the  functionality  similar  to  FAA 
Tower  Control  Systems.  This  system  provides  for  the  control  of  ground  travel  and  issuance  of 
takeoff/landing  clearances. 

A  DoD  Advanced  Automation  System  will: 

•  accept,  process,  allow  in-flight  modification  and  closeout  of  flight  plans; 

•  provide  communication  between  controller  and  aircraft; 

•  provide  weather  information  and  re-route  controlled  traffic  accordingly; 

•  provide  traffic  re-routing  due  to  exceptional  conditions  (e.g.  aircraft  emergency,  airport  closing,  etc.), 

A  typical  scenario  for  operating  an  aircraft  under  the  guidance  of  a  a  DoD  Advanced  Automation  System  for 
Air  Traffic  Control  involves  the  following: 

•  Pre-Flight 

-  Flight  plan  entry 

•  Departure  (Tower/ Area) 
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-  Push  back  clearance 

-  Taxi  clearance 

-  Take-off  clearance 

•  In-Flight  (Area) 

—  Spacing,  monitoring,  and  tracking  of  aircraft 

•  Approach  (Area) 

-  Sequencing  and  spacing  of  aircraft  to  determine  landing  order 

•  Landing  (Area/Tower) 

—  Landing  clearance 
—  Taxi  clearance 

—  Docking  clearance 

•  Post-Flight 

—  Close-out  flight  plan 

This  scenario  is  depicted  in  Figure  1  on  page  6. 
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FLYING  THROUGH  THE  NATIONAL  AIRSPACE  SYSTEM 
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Figure  1.  Flying  through  the  National  Airspace.  This  figure  illustrates  a  typical  scenario  for  operating  an  aircraft 
under  the  guidance  of  a  a  DoD  Advanced  Automation  System  for  Air  Traffic  Control. 
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Overview  of  DoD  Advanced  Automation  System 

The  DoD  Advanced  Automation  System  can  be  characterized  as  three  subsystems.  These  are: 

•  National  Flow  Control  (level  0  (layer  3.5)  of  the  DoD  AAS) 

•  Area  Control  Facility  (level  1  (layer  3)  of  the  DoD  AAS) 

•  Tower  Control  Facility  (level  1  (layer  3)  of  the  DoD  AAS). 

The  system  context  diagram  for  the  DoD  AAS  is  presented  in  Figure  2  on  page  8  This  figure  illustrates  the 
system  boundaries  for  the  DoD  Advanced  Automation  System  and  its  interfaces. 

Figure  3  on  page  9  illustrates  the  layered  view  of  the  DoD  Advanced  Automation  System  and  provides  the 
view  of  the  functional  objects  inside  the  DoD  Advanced  Automation  System.  This  layered  view  illustrates 
the  major  functional  objects  of  the  DoD  AAS  and  their  place  in  the  functional  object  hierarchy  (also  known 
as  the  functional  object  tree),  based  on  their  ‘White  Layered  Model'  capabilities  and  roles.  The  "White 
Layered  Model'  will  be  described  in  the  IQM15  Phase  III  deliverable. 

The  top  functional  object  of  the  DoD  AAS  functional  object  tree  is  the  National  Flow  Controller  which  is 
illustrated  in  Figure  4  on  page  1 1  The  functional  object  tree  for  the  DoD  AAS  identifies  the  National  Flow 
Control  Diagram  as  DoD  AAS  level  1.  Figure  5  on  page  13  illustrates  the  Area  Control  Facility  and  Tower 
diagram,  which  is  identified  as  DoD  AAS  level  2  on  the  functional  object  tree. 

Figure  6  on  page  14  provides  the  system  context  for  the  Area  Control  Facility  and  Figure  7  on  page  15 
provides  the  system  context  for  the  Tower  Control  Facility. 
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Figure  2.  DoD  Advanced  Automation  System  Context  Diagram.  This  figure  shows  the  system  context  for  the  DoD 
AAS  and  the  information  flow  to  and  from  its  interfaces. 
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Figure  3.  DoD  Advanced  Automation  System  Functional  Object  Tree.  This  figure  shows  the  major  functional 

objects  of  the  DoD  Advanced  Automation  System  and  their  hierarchical  relationship  to  one  another.  These 
objects  are  layered,  based  on  their  functional  capabilities. 
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National  Flow  Controller 

The  Area  Control  Facilities  shall  interface  with  the  National  Flow  Controller  through  an  X.25  packet 
switching  system  called  the  NADIN.  The  National  Flow  Controller  is  the  focal  point  for  the  management 
of  nationwide  air  traffic  flow  .  The  National  Flow  Controller  receives  flight  plans  (including  VFR  flight  plans 
for  adapted  airports),  arrival  and  departure  messages,  flight  plan  amendments  (including  changes  to  bulk 
store  and  proposed  flight  plans),  expected  departure  clearance  times  (EDCT),  cancellations,  metering  and 
data  block  information,  flow  restrictions,  the  status  of  local  metering,  changes  in  area  control  facility  (ACF) 
sector  capacity  and  configuration  (including  fix  and  airway  capacities),  traffic  statistics,  and  airport  configura¬ 
tion  and  capacity  data  for  adapted  airports. 

The  National  Flow  Controller  transmits  arrival  and  departure  demand  lists,  altitude  reservations  (ALTRV), 
airport  reservation  lists,  alerts  where  projected  demand  exceeds  capacity  (i.e.  for  arrivals,  departures,  sectors, 
airways  and  fixes),  expected  departure  clearance  times,  and  track  position  and  data  block  information  (for 
adjacent  Area  Control  Facilities).  Figure  4  on  page  11  illustrates  the  information  flow  to  and  from  the 
National  Flow  Controller. 
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and  the  Area  Control  Facility,  illustrated  at  a  subordinate  level  in  Figure  5  on  page  13. 
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IOM  Diagram  Note 

Note  in  Figure  4  on  page  11,  that  information  flows  to  and  from  its  subordinate  object,  the  Area  Control 
Facility.  In  a  structured  analysis  repress  tion,  this  would  not  be  proper.  Since  the  National  Flow  Con¬ 
troller  is  responsible  for  monitoring  a  picture  of  the  national  airspace,  it  receives  traffic  and  weather  surveil¬ 
lance  data  from  the  Area  Control  Facilities,  along  with  flight  information.  In  turn,  the  National  Flow 
Controller  'controls'  Area  Control  Facilities  operations  by  providing  them  with  airspace  capacity  alerts, 
based  on  national  traffic  projections. 

It  is  the  hierarchic  organization  of  objects,  based  on  their  capabilities,  and  the  information  and  control  mes¬ 
sages  passed  to  subordinate  objects  that  makes  the  IOM  transformation  modeling  unique. 

It  should  also  be  noted  that  the  National  Flow  Controller,,  as  an  object,  performs  work.  Its  subordinate 
objects  may  or  may  not  represent  its  decomposition.  In  the  case  presented  in  Figure  4  on  page  li,  the  Area 
Control  Facility  and  Tower  Control  Facility  are  not  functions  of  the  National  Flow  Controller,  in  a  decom¬ 
position  sense.  However,  from  a  control  as  well  as  functional  capability  standpoint,  they  are  subordinate  to 
the  National  Flow  Controller.  As  all  'functional'  objects  must  perform  work,  (thus  the  term  functional), 
some  constructions  will  appear  incorrect  to  practitioners  of  structured  analysis,  but  from  an  IOM  modeling 
standpoint,  they  are  perfectly  reasonable. 
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Area  Control  Facility  and  Tower  Control  Facility 

Figure  5  illustrates  the  information  flow  to  and  from  the  Area  Control  Facility  and  the  Tower  Control 
Facility,  and  to  the  National  Flow  Controller. 


Figure  5.  Area  Contiol  Facility  and  Tower  Control  Facility.  This  figure  illustrates  the  information  flow  between  the 


National  Flow  Controller  and  the  Area  Control  Facility,  illustrated  at  a  subordinate  level  in  Figure  5. 
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DoD  AAS  Area  Control  Facility  Context 

Figure  6  illustrates  the  system  boundaries  for  the  DoD  AAS  Area  Control  Facility  and  its  interfaces.  The 
DoD  AAS  Area  Control  Facility  is  the  lirst  of  two  subordinate  Information  Object  Models  required  to 
describe  the  DoD  AAS.  As  discussed  previously,  the  focus  of  the  remainder  of  this  document  in  on  the 
DoD  AAS  Area  Control  Facility. 
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Figure  6.  DoD  AAS  Area  Control  Facility  Context  Diagram.  This  figure  shows  the  system  context  for  the  DoD  AAS 
Area  Control  Facility  and  the  information  flow  to  and  from  its  interfaces. 
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DoD  AAS  Tower  Control  Facility  Context 


Figure  7  illustrates  the  system  boundaries  for  the  DoD  AAS  Tower  Control  Facility  and  its  interfaces.  The 
DoD  AAS  Tower  Control  Facility  IOM  is  the  second  of  two  subordinate  Information  Object  Models 
required  to  describe  the  DoD  AAS.  As  discussed  previously,  the  focus  of  the  remainder  of  this  document  in 
on  the  DoD  AAS  Area  Control  Facility.  This  diagram  is  included  for  reference. 


Figure  7.  DoD  AAS  Tower  Control  Facility  Context  Diagram.  This  figure  shows  the  system  context  for  the  DoD 
AAS  Tower  Control  Facility  and  the  information  flow  to  and  from  its  interfaces. 
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Overview  of  Area  Control  Facility 

The  focus  of  the  remainder  of  this  document  will  be  on  the  DoD  AAS  Area  Control  Facility,  as  this  is  the 
area  we  chose  to  develop  in  scoping  the  DoD  AAS  modeling  effort.  DoD  AAS  can  best  be  represented  by 
three  Information  Object  Models: 

•  DoD  AAS  IOM,  which  was  informally  presented  in  the  previous  section, 

•  DoD  AAS  Area  Control  Facility  IOM 

•  DoD  AAS  Tower  Control  Facility  IOM. 

This  allocation  was  selected  because  of  the  requirements  for  modeling  an  IOM.  As  all  functional  objects 
must  perform  one  or  more  functions,  and  traditional  functional  decomposition  to  functional  primitives  is  not 
allowed,  this  approacn  was  necessary.  Traditional  structured  analysis  transformation  diagram  decomposition 
permits  processes  which  are  'hollow"  in  that  the  process  bubble  represents  an  encapsulation  of  functions 
described  at  lower  levels.  In  IOM  transformation  diagram  decomposition,  all  functional  objects  and  the 
processes  used  to  describe  the  functions,  must  perform  work.  The  method  we  chose  of  partitioning  DoD 
AAS  into  three  IOMs  was  the  most  practical  solution  that  we  found  to  adhere  to  the  IOM  modeling  rules. 


Major  Functional  Objects  for  the  Area  Control  Facility  IOM 

The  Area  Control  Facility  Information  Object  Model  can  be  fiinctionally  described  as  a  collection  of  eight 
different  areas,  namely: 

1.  Traffic  Surveillance 

2.  Weather  Surveillance 

3.  Aircraft  and  Track  Management 

4.  Recording  Support 

5.  Prediction  and  Resolution 

6.  Flight  Plan  Entry  Support 

7.  Flight  Plan  Operations  Support 

8.  Area  Control. 

Figure  8  on  page  18  identifies  the  eight  functional  areas  and  illustrates  the  information  flow  between  the 
functional  areas.  The  system  as  described  must  interact  with  external  factors,  which  are  illustrated  in 
Figure  9  on  page  19.  These  external  factors  are: 

1.  Information  input: 

•  Weather 

•  Real-time  weather  processor 

•  Weather  agency 

•  Flight  service  data  processing 

•  Oceanic  Flight  Data  Processing 

•  Air  traffic 

•  WWV 

•  National  Flow  Control 
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•  National  Flow  Control 

2.  Information- Output: 

•  NORAD 

3.  Information  Input  and  Output 

•  Tower  Control 

•  Aircraft 

•  Airway  Facilities. 
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Figure  9  DoD  A  AS  Area  Control  System  Context  Diagram.  This  figure  illustrates  the  external  factors  which  the 
Area  Control  System  must  interface.  The  diagram  also  establishes  the  system  boundary  for  the  Area 
Control  System  and  illustrates  the  information  flow  between  external  interfaces. 
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1.0  Traffic  Surveillance 

The  1.0  TRAFFIC  SURVEILLANCE  object  shall  present  to  air  traffic  controllers,  a  consistent  view  of 
traffic  conditions  in  a  given  sector  of  airspace.  This  view  of  traffic  conditions  will  be  provided  from  raw 
sensor  data  collected  from  both  primary  and  secondary  radar  systems  and  processed  to  filter  and  present 
radar  information  to  air  traffic  controllers. 


2.0  Weather  Surveillance 

The  2.0  WEATHER  SURVEILLANCE  object  shall  present  to  air  traffic  controllers,  an  integrated  picture  of 
weather  conditions,  overlayed  with  information  from  flight  plan  processing  and  the  prediction  and  resolution 
function.  This  view  of  weather  conditions  will  be  provided  from  raw  sensor  data  collected  from  both 
primary  and  secondary  radar  systems  and  processed  to  filter  and  present  radar  information  to  air  traffic  con¬ 
trollers. 


3.0  Prediction  and  Resolution 

The  3.0  Prediction  And  Resolution  object  shall  perform,  all  tactical  and  strategic  prediction  and  resolution  of 
conflicts.  Tactical  prediction  and  resolution  is  based  on  realtime  flight  surveillance  data.  It  is  concerned 
with  identifying  imminent  conflicts  and  does  so  by  analyzing  current  and  historical  flight  path  data.  Any 
conflict  arising  in  the  next  few  minutes  is  identified  to  the  Controller,  along  with  a  list  of  possible  evasive 
maneuvers.  Possible  conflicts  are  between  aircraft  and  aircraft,  or  between  aircraft  and  the  ground. 

Strategic  prediction  and  resolution  functions  are  concerned  with  future  conflicts,  and  these  functions  base 
their  analysis  on  recorded  flight  plan  data.  Using  the  flight  plan  data,  this  function  will  simulate  airspace 
into  the  future  to  predict  aircraft  to  aircraft  and  aircraft  to  ground  conflicts.  This  function  will  also  predict  if 
too  many  planes  are  entering  a  window  of  airspace  within  a  certain  time  window.  Identified  conflicts  are 
presented  to  the  Controller,  who  has  the  option  of  requesting  resolution  of  identified  conflicts  in  the  form  of 
updated  flight  plans. 


4.0  Recording  Support 

4.0  Recording  Support  object  shall  provide  the  air  traffic  control  system  the  ability  to  log  required  system 
data.  Recording  Support  contains  the  recording  of  air  traffic  management  data,  system  hardware  and  soft¬ 
ware  diagnostic  and  performance  information,  and  data  to  determine  flight  monitoring  statistics. 

Air  traffic  management  data  includes  activity  counts  taken  within  air  traffic  control  sectors.  These  counts 
include: 

•  Number  of  IFR  aircraft  and  controller  VFR  aircraft 

•  Adapted  routes 

•  Speed  distribution 

•  Altitude  distribution 

•  Number  of  arrivals 

•  Number  of  departures 

•  Number  of  overflights 

•  Number  of  flight  plans 
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•  Number  of  separation  incidents. 

Flight  monitoring  statistics  shall  be  recorded  to  determine  the  average  times  and  speeds  of  flights  within 
sectors  and  sectors  traversed  per  flight. 


5.0  Aircraft  and  Track  Management 

The  5.0  Aircraft  and  Track  Management  object  shall  perform  the  function  of  correlating  identified  aircraft 
surveillance  tracks  to  flight  plans  recorded  in  the  database.  For  tracks  with  identified  flight  plans,  any  flight 
plan  milestone  is  recorded,  including  metering  fix  crossings. 


6.0  Flight  Plan  Entry  Support 

The  6.0  Flight  Plan  Entry  Support  object  shall  provide  a  single  point  in  the  system  for  the  entry  of  and 
updates  to  flight  plans.  Four  types  of  flight  plan  entries/updates  will  be  processed:  initial  flight  plans  and 
amendments,  up-route  and  trial  flight  plans,  updates  to  flight  plan  times  (actual  and  estimated)  or  status,  and 
handoffs  of  flight  plans  entering  the  air  space. 

There  are  five  databases  which  are  updated  by  the  Flight  Plan  Entry  Support  object.  The  Inactive  Flight 
Plan  Database  contains  flight  plans  which  have  been  entered  into  the  system,  but  which  have  not  yet 
departed.  When  a  flight  departs,  it  is  moved  to  the  Active  Flight  Plan  Database.  Flights  which  are  currently 
active  in  up-route  centers  are  kept  in  the  Up-Route  Active  Flight  Plan  Database.  Trial  flight  plans  are  kept 
in  the  Trial  Flight  Plan  Database.  When  they  have  been  approved  by  the  controller,  they  are  moved  to  the 
Active  Flight  Plan  Database  or  the  Inactive  Flight  Plan  Database  as  appropriate.  Flight  plans  received  in 
bulk  are  stored  in  the  Bulk  Flight  Plan  Database  until  needed. 

When  the  Flight  Plan  Entry  Support  object  receives  a  new  flight  plan,  a  bulk  flight  plan,  or  an  amendment 
to  a  flight  plan  (to  either  an  active  or  inactive  flight),  syntax  checking  and  geographical  checking  is  per¬ 
formed.  If  an  error  exists,  the  enterer  of  the  flight  plan  is  notified.  Otherwise,  the  flight  plan  is  stored  in  the 
appropriate  database.  Bulk  flight  plans  are  stored  in  the  Bulk  Flight  Plan  Database  until  an  adapted  amount 
of  time  prior  to  departure.  At  this  time,  they  are  sent  to  Flight  Plan  Operation  Support  for  further  route 
processing. 

When  trial  or  up-route  flight  plans  are  received,  they  are  stored  in  the  appropriate  databases,  and  Flight  Plan 
Operation  Support  is  notified. 

When  an  update  to  an  estimated  or  actual  time  in  a  flight  plan  is  received,  or  a  change  to  a  flight  plan  status 
is  received,  the  appropriate  flight  plan  database  is  updated,  and  Flight  Plan  Operation  Support  is  notified. 

When  a  handoff  coming  into  the  center  is  received,  the  controller  is  notified.  When  the  controller  receives 
the  handoff,  the  flight  plan  is  deleted  from  the  Up- Route  Flight  Plan  Database,  and  entered  in  the  Active 
Flight  Plan  Database. 


7.0  Flight  Plan  Operation  Support 

The  7.0  Flight  Plan  Operation  Support  object  shall  perform  three  functions:  expand  the  route  in  a  flight 
plan,  update  fix  data  when  an  estimated  or  actual  time  in  a  flight  plan  changes,  and  generate  strips  and 
handoff  requests. 

.An  adapted  time  prior  to  departure,  the  route  of  a  flight  plan  is  expanded  to  include  all  fixes  along  the  route. 
This  processing  may  be  repeated  after  departure  if  the  flight  plan  is  amended. 
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Every  time  a  time  in  a  flight  plan  is  modified  (either  an  actual  or  an  estimated  time),  the  fix  data  for  that 
flight  plan  is  recalculated.  The  fix  data  includes  the  estimated  time  of  arrival  at  each  fix  and  the  destination, 
as  well  as  the  Meterable  Fix  Counts  Database. 

At  an  adapted  time  prior  to  arrival  at  a  center  or  sector,  a  strip  is  generated  for  that  center  or  sector.  Also, 
at  an  adapted  time  prior  to  arrival  at  a  center  or  sector,  a  handoff  request  is  generated  and  sent  to  the 
receiving  center  or  sector. 


8.0  Area  Control 

The  8.0  Area  Control  object  shall  be  responsible  for  airspace  management,  which  includes  monitoring 
defined  areas  of  airspace,  and  controlling  air  traffic,  under  Area  Control.  Further,  it  shall  provide  Area  Flow 
Control,  which  will  interface  with  the  National  Flow  Controller,  for  the  effective  and  safe  utilization  of  air¬ 
space  and  managing  airspace  congestion. 

The  8.0  AREA  CONTROL  object  encapsulates  the  functions  of  the  Enroute  and  Approach  Control  Facili¬ 
ties. 
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Information  Object  Models  (IOM) 

This  section  provides  the  Information  Object  Models  for  the  major  functional  objects.  The  functional 
objects  presented  are: 

•  1.0  Traffic  Surveillance 

•  2.0  Weather  Surveillance 

•  3.0  Prediction  and  Resolution 

•  5.0  Aircraft  and  Track  Management 

•  6.0  Flight  Plan  Entry  Support 

•  7.0  Flight  Plan  Operation  Support 

•  8.0  Area  Control 

•  4.0  Recording  Support. 

Functional  objects  8.0  Area  Control  and  4.0  Recording  Support  are  included,  but  are  not  complete.  They 
were  prepared  from  existing  documentation  and  the  materials  prepared  for  the  final  review.  Personnel 
assigned  to  these  sections  were  reassigned  after  the  the  QM15  final  review,  and  were  unable  to  finish  docu¬ 
menting  their  sections. 
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1.0  Traffic  Surveillance 

Introduction 

The  Traffic  Surveillance  object  is  responsible  for  providing  air  traffic  surveillance  information  to  Area 
Control  for  final  processing  to  display  an  integrated  view  of  air  traffic  to  air  traffic  controllers. 

The  TRAFFIC  SURVEILLANCE  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Traffic  Surveillance  View  From 

•  The  Traffic  Surveillance  Interfaces 

•  The  Traffic  Surveillance  Functional  Object  Tree 

•  Traffic  Surveillance. 

1.0  Traffic  Surveillance  "View  From" 

The  DoD  AAS  Area  Control  view  from  1.0  TRAFFIC  SURVEILLANCE  is  illustrated  by  Figure  10  on 
page  25.  The  'view  from'  presents  all  of  the  major  functional  objects  of  the  DoD  AAS  Area  Control  and 
their  relationship  to  TRAFFIC  SURVEILLANCE  by  the  messages  that  are  passed  to  and  from  it. 

The  TRAFFIC  SURVEILLANCE  object  provides  traffic  surveillance  data  to  following  objects:  1)  5.0  Air¬ 
craft  and  Track  Management,  2)  3.0  Prediction  and  Resolution,  3)  4.0  Recording  Support,  and  4)  8.0  Area 
Control.  Traffic  Surveillance  also  provides  weather  map  messages  to  weather  surveillance  for  weather  sur¬ 
veillance  processing.  Finally  Traffic  surveillance  updates  the  track  history  database  for  reference  by  other 
objects. 
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Figure  10.  DoD  AAS  Area  Control  View  from  Traffic  Surveillance.  This  figure  illustrates  the  view  of  DoD  AAS 

Area  Control  with  respect  to  TRAFFIC  SURVEILLANCE.  This  diagram  also  presents  all  of  the  major 
functional  objects  of  the  DoD  AAS  Area  Control  IOM  and  the  message  'pipes'  that  connect  them  to 
TRAFFIC  SURVEILLANCE. 
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1.0  Traffic  Surveillance  Interfaces 

The  interfaces  to  TRAFFIC  SURVEILLANCE  are  illustrated  on  Figure  1 1  on  page  27.  It  provides  traffic 
surveillance  data  to  object's  Prediction  and  Resolution,  Aircraft  and  Track  Management,  and  recording 
support.  Traffic  surveillance  display  data  is  sent  to  Area  Control.  Radar  Site  Failure/Reset  reports  are  send 
to  Recording  support  for  logging.  Track  History  Updates  are  recorded  in  the  Track  History  database  for 
future  reference  by  other  objects.  Weather  Map  Messages  are  sent  to  weather  surveillance  for  assembling  a 
view  of  the  weather  for  presentation  by  Area  Control.  Traffic  Surveillance  receives  Raw  Radar  Returns  from 
air  traffic  surveillance  radars. 
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1.0  TRAFFIC  SURVEILLANCE  INTERFACES 
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Figure  1 1.  Interfaces  for  1.0  TRAFFIC  SURVEILLANCE.  This  figure  illustrates  the  interfaces  of  the  the  1.0  TralTic 
Surveillance  functional  object.  This  diagram  shows  the  major  inputs  from  other  DoD  AAS  Area  Control 
functional  objects  and  external  interfaces. 
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1.0  Traffic  Surveillance  Inputs 

Traffic  surveillance  inputs  are  provided  from  external  sensors  to  the  traffic  surveillance  object,  thus  they  are 
not  displayed  on  the  'view  from'  which  only  shows  communications  inside  the  DoD  AAS  Area  Control 
IOM.  Sensor  input  is  received  in  the  form  of  raw  radar  data  and  radar  codes  from  primary  and  secondary 
traffic  surveillance  radars. 

1.0  Traffic  Surveillance  Outputs  * 

•  WEATHER_MAP_MESSAGES  -  Weather  radar  messages  that  have  been  prepared  by  the  air  traffic 
surveillance  radar  sites; 

•  TRAFFIC_SURV_DISPLAY_DATA  -  Normalized  traffic  surveillance  data  sent  to  Area  Control  for 
display  processing; 

•  TRAFFIC_SURVELLANCE_DATA  -  Radar  surveillance  data  of  air  traffic  that  has  been  normalized 
for  further  processing  and  use  by  other  ATC  subsystems; 

•  TRACK_HISTORY_UPDATES  -  Aircraft  target  track  messages  are  stored  in  the  TRACK_HISTORY 
database  for  reference  by  other  ATC  subsystems; 

•  RADAR_SITE_FAILURE/RESET_REPORT  -  Radar  action  reports  sent  to  RECORDING 
SUPPORT  for  event  logging  and  further  action.  Reports  are  sent  upon  radar  state  change; 

1.0  Traffic  Surveillance  Functional  Object  Tree 

The  functional  object  tree  for  1.0  TRAFFIC  SURVEILLANCE  presents  the  object  hierarchy  of  TRAFFIC 
SURVEILLANCE,  as  illustrated  in  Figure  12  on  page  29  The  functional  object  tree  presents  all  of  the 
graphics  used  to  describe  TRAFFIC  SURVEILLANCE,  as  well  as  the  message  communication  paths  that 
show  communication  between  peer  objects,  parent  objects  to  child  objects,  and  child  to  j  irent  objects. 
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1.0  TRAFFIC  SURVEILLANCE  FUNCTIONAL  OBJECT  TREE 
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Figure  12.  Functional  Object  Tree  for  1.0  Traffic  Surveillance.  This  figure  illustrates  the  functional  object  tree  fo;  the 
TRAFFIC  SURVEILLANCE  functional  object.  This  tree  shows  the  hierarchic  relationship  between  the 
subordinate  functional  objects  and  shows  message  passing  between  peer  objects,  parent  objects  and  child 
objects  on  different  levels,  It  also  identifies  the  communication  paths  between  the  decomposition  levels. 
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1.0  Traffic  Surveillance  Discussion 

The  purpose  of  TRAFFIC  SURVEILLANCE  is  to  present  to  air  traffic  controllers  a  consistent  view  of 
traffic  conditions  in  a  given  sector  of  airspace.  This  view  of  traffic  conditions  is  provided  from  raw  sensor 
data  collected  from  both  primary  and  secondary  -adar  systems  and  processed  to  filter  and  present  radar  infor¬ 
mation  to  air  traffic  controllers.  TRAFFIC  SURVEILLANCE  is  illustrated  in  Figure  13  on  page  31.  The 
major  roles  of  traffic  surveillance  are: 

•  Aircraft  surveillance 

•  Weather  clutter  identification 

•  ECM  jamming  identification. 
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Figure  13.  1.0  TRAFFIC  SURVEILLANCE.  This  figure  illustrates  TRAFFIC  SURVEILLANCE  and  its  children 
objects  1.1  RADAR  SUPERVISOR  and  1.2  TARGET  DATA  PROCESSING. 


1.0  Traffic  Surveillance 


31 


STARS  Deliverable  1200 


1.1  Radar  Supervisor 

1.1  Description 

The  1.1  RADAR  SUPERVISOR  object  shall  examine  radar  data  from  Mode  S  Radar  Beacon  Sites  (sec¬ 
ondary  radar  "jitcs)  and  primary  radar  sites  to  determine  radar  failures.  Any  radar  failures  found  shall  be 
logged  for  review  by  Airway  Facilities  to  take  the  appropriate  corrective  action.  Airway  Facilities  will 
assume  all  responsibilities  for  equipment  maintenance  and  repair.  Further,  upon  error  discovery,  the 
RADAR  SUPERVISOR  shall  declare  the  suspect  radar  invalid  and  shall  issue  instructions  for  reports  from 
the  invalid  radar  to  be  filtered  out.  Counts  provided  from  the  RADAR  DATA  COUNTING  object  are 
analyzed  to  determine  if  there  are  excessive  or  missing  types  of  targets  and  to  declare  a  site  with  missing  or 
excessive  targets  or  errors  as  a  failed  radar  site.  Finally,  the  RADAR  SUPERVISOR  shall  provide  a 
message  routing  function  taking  the  basic  filtered  target  reports  received  and  forward  them  to  TARGET 
DATA  PROCESSING  for  further  processing. 

1.1  Inputs 

•  RADAR_TEST_STATUS_MESSAGES  -  A  test  or  status  message  received  from  a  radar  site  indicating 
equipment  status 

•  RADAR_STROBE_MESSAGE  -  A  message  indicating  that  jamming  of  primary  or  secondary  radar  site 
data  is  in  effect,  or  is  no  longer  in  effect 

•  TARGET_COUNTS  -  A  count  of  the  radar  returns  for  a  given  radar  site 

•  TARGET_ERROR_COUNTS  -  A  count  of  the  errors  in  the  radar  returns  for  a  given  radar  site.  The 
count  is  used  to  check  the  status  of  the  site's  radars 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  coverage  areas 

•  ENABLE_DISABLE_RADAR  -  A  discrete  message  sent  indicating  that  a  selected  radar  is  to  be 
enabled  or  disabled.  The  message  is  addressed  (via  RADAR_ID)  to  a  particular  site  radar.  An  enable 
radar  message  is  sent  after  a  radar  has  been  repaired.  A  disable  radar  message  is  sent  upon  error  dis¬ 
covery  and  validation. 

1.1  Outputs 

•  RADAR_RESET  -  Notification  of  a  reset  of  a  primary  or  secondary  radar  site 

•  RADAR_FAILURE_NOTIFICATION  -  Notification  of  the  failure  of  a  primary  or  secondary  radar 
site 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  coverage  areas 

•  RADAR_SITE_FAILURE_REPORT  -  Report  indicating  that  a  radar  site  has  failed.  Airway  Facilities 
receives  this  data,  and  makes  the  appropriate  action  determination 

1.2  Target  Data  Processing 

1.2  Description 

TARGET  DATA  PROCESSING  object  shall  filter  out  all  FILTERED_TARGET_REPORTS  that  are  out 
of  the  boundaries  for  a  given  area  of  airspace,  and  route  the  remaining  FILTERED_TARGET_REPORTS 
to  children  objects  for  further  processing.  TARGET  DATA  PROCESSING  shall  normalize  data  collected 
from  multiple  radars  to  provide  consistent  information  about  a  given  target. 
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1.2  Inputs 

•  TRAFFIC_SURVELLANCE_DATA  -  Air  Traffic  Radar  surveillance  data  that  has  been  normalized  for 
further  processing  by  other  ATC  subsystems  and  for  use  in  assembling  integrated  view  data  for  presenta¬ 
tion.  Data  may  contain  data  overlapping  other  sector's  airspace  boundaries  that  require  elimination  for 
sector  processing. 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  have  only  nonstationary 
targets  from  good  sites  and  nonrestricted  coverage  areas. 

1 .2  Outputs 

•  TRAFFIC_SURVELLANCE_DATA  -  Air  Traffic  radar  surveillance  data  that  has  been  normalized  for 
further  processing  by  other  ATC  subsystems  and  for  use  in  assembling  integrated  view  data  for  presenta¬ 
tion. 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  coverage,  areas;  Target  data  outside  of  the  sector's  airspace 
boundaries  have  been  filtered  out. 
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1.1  Radar  Supervisor  Discussion 

The  1.1  RADAR  SUPERVISOR  object  shall  examine  radar  data  from  Mode  S  Radar  Beacon  Sites  (sec¬ 
ondary  radar  sites)  and  primary  radar  sites  to  determine  radar  failures.  Any  radar  failures  found  shall  be 
logged  for  review  by  Airway  Facilities  to  take  the  appropriate  corrective  action.  Airway  Facilities  will 
assume  all  responsibilities  for  equipment  maintenance  and  repair.  Further,  upon  error  discovery,  the 
RADAR  SUPERVISOR  shall  declare  the  suspect  radar  invalid  and  shall  issue  instructions  for  reports  from 
the  invalid  radar  to  be  filtered  out.  Counts  provided  from  the  RADAR  DATA  COUNTING  object  are 
analyzed  to  determine  if  there  are  excessive  or  missing  types  of  targets  and  to  declare  a  site  with  missing  or 
excessive  targets  or  errors  as  a  failed  radar  site.  Finally,  the  RADAR  SUPERVISOR  shall  provide  a 
message  routing  function  taking  the  basic  filtered  target  reports  received  and  forward  them  to  TARGET 
DATA  PROCESSING  for  further  processing.  1.1  RADAR  SUPERVISOR  is  illustrated  in  Figure  14  on 
page  35.  The  state  transition  diagram  illustrating  the  behavior  of  RADAR  SUPERVISOR  given  radar 
status  is  illustrated  in  Figure  15  on  page  36. 
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Figure  14.  1.1  RADAR  SUPERVISOR.  This  figure  illustrates  RADAR  SUPERVISOR  and  its  children  objects, 
1.1.1  RADAR  COUNTING,  1.1.2  RADAR  REPORT  FILTER,  1.1.3  ECM  DETECTOR,  1  1  4 
NON-TARGET  DATA  PROCESSING. 
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Figure  15.  1.1  RaDAR  SUPERVISOR  BEHAVIOR.  This  figure  illustrates  the  state  transition  diagram  for 
changing  between  three  states,  namely:  RADAR  ONLINE,  RADAR  INVALID,  and  RADAR 
OFFLINE. 


1.0  Traffic  Surveillance  36 


STARS  Deliverable  1200 


1.1.1  Radar  Data  Counting 

1.1.1  Description 

The  RADAR  DATA  COUNTING  object  shall  examine  radar  counts  to  ascertain  excesses  or  failures  in 
radar  data  received  from  reporting  radar  sites.  Counts  shall  be  maintained  for  number  of  targets  and  target 
errors  received  from  each  radar  site. 

1 .1 .1  Inputs 

•  DIGITIZED_RADAR_REPORTS  -  Digitized  radar  target  reports. 

1 .1 .1  Outputs 

•  TARGET_COUNTS  -  A  count  of  the  radar  returns  for  a  given  radar  site; 

•  TARGETJERROR_COUNTS  -  A  count  of  the  errors  in  the  radar  returns  for  a  given  radar  site.  The 
count  is  used  to  check  the  status  of  the  sites. 

1.1.2  Radar  Report  Filter 

1.1.2  Description 

The  RADAR  REPORT  FILTER  object  shall  reduce  the  number  of  radar  returns  to  be  processed.  Radar 
returns  shall  be  discarded  if  they  are  received  from  failed  radar  sites.  Radar  returns  may  also  be  discarded 
where  aircraft  are  in  areas  where  aircraft  target  detection  may  be  restricted  or  inhibited,  or  if  the  mode  C 
altitude  return  is  determined  to  be  unreasonable.  The  type  of  target  is  also  identified  so  that  targets  such  as 
military  targets  can  be  forwarded  directly  to  NORAD  for  processing.  Further,  based  on  military  beacon 
codes  and  military  area  coverage  requirements,  reports  can  be  filtered  to  mask  out  military  flights  and  air¬ 
space,  as  required. 

Masking  is  the  process  of  filtering  radar  data  by  area,  and  is  used  to  reduce  the  number  of  radar  returns  to  be 
processed  by  the  remaining  subprograms.  Areas  with  more  than  double  radar  coverage  are  considered  for 
masking,  which  is  applied  selectively  on  a  Rho, Theta  basis  for  each  radar.  The  mask  for  each  radar  is  con¬ 
trolled  by  the  adaptation  parameters  which  is  used  to  compensate  for  radar  failures. 

Mode  C  altitude  shall  be  checked  for  reasonableness  and  unreasonable  altitudes  shall  be  discarded.  The 
mode  C  altitude  is  compared  with  adapted  aircraft  characteristics  and  unreasonable  altitudes  discarded. 

The  state  transition  diagram  describing  the  behavior  of  the  RADAR  REPORT  FILTER  object  for  transi¬ 
tioning  between  radar  validity  states  is  depicted  in  Figure  16  on  page  39. 

1.1.2  Inputs 

•  DIGITIZED_RADAR_REPORTS  -  Digitized  radar  target  reports; 

•  RADAR_RESET  -  Notification  of  a  reset  of  a  primary  or  secondary  radar  site; 

•  RADAR_FAILURE_NOTIFICATION  -  Notification  of  the  failure  of  a  primary  or  secondary  radar 
site; 

•  JAMMED_RADAR_REPORTS  -  Radar  reports  that  are  declared  invalid  due  to  a  jamming  condition; 

•  RADAR_COVERAGE  (DATA  STORE)  -  to  provide  RADAR  REPORT  FILTER  with  radar  cov¬ 
erage  area; 
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•  MILITARY_BEACON_CODES  (DATA  STORE)  -  to  provide  RADAR  REPORT  FILTER  with  the 
ability  to  identify  military  beacon  codes; 

•  AIRCRAFT_,CHARACTERISTICS  (DATA  STORE)  -  to  provide  RADAR  REPORT  FILTER  with 
the  ability  to  determine  whether  or  not  a  return  is  an  aircraft. 

1.1.2  Outputs 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  areas; 

•  MIL1TARY_PRIMARY_RADAR_TARGETS  -  Primary  radar  returns  that  are  for  military  aircraft; 

•  MILITARY_BEACON_CODES  -  Beacon  codes  from  military  aircraft; 

•  BAD_SITE_RADAR_DATA  •  Radar  data  that  is  received  from  a  radar  site  that  has  a  failure  status. 
The  data  is  discarded  (shewn  as  going  into  the  BIT  BUCKET  on  Figure  14  on  page  35. 

•  STATIONARYJTARGETS  -  Stationary  radar  targets  that  are  discarded  as  non-targets  (shown  as  going 
into  the  BIT  BUCKET  on  Figure  14  on  page  35; 

•  RESTRICTED_AREA_RADAR_DATA  -  Radar  returns  from  a  restricted  area  that  are  discarded 
(shown  as  going  into  the  BIT  BUCKET  on  Figure  14  on  page  35. 


1.0  Traffic  Surveillance  38 


STARS  Deliverable  1200 


Figure  16.  1.1.2  RADAR  REPORT  FILTER.  This  figure  illustrates  the  state  transition  diagram  for  changing 
between  two  states,  namely:  RADAR  VALID  and  RADAR  INVALID. 
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1.1.3  ECM  Detection 

1.1.3  Description 

The  ECM  DETECTOR  object  shall  identify  radar  returns  that  have  originated  in  an  area  which  is  being 
jammed  by  electromagnetic  counter  measures. 

1.1.3  Inputs 

•  DIGITIZED_RADAR_REPORTS  -  Digitized  radar  target  reports. 

1.1.3  Outputs 

•  JAMMED_RADAR_REPORTS  -  Radar  reports  that  are  declared  invalid  due  to  a  jamming  condition. 

1.1.4  Non-Target  Processing 

1.1.4  Description 

Non-target  as  well  as  target  messages  are  received  from  the  primary  and  secondary  radar  sites.  Non-Target 
Processing  monitors  the  test  and  status  messages,  generates  a  strobe  message,  and  forwards  the  map  messages 
to  weather  surveillance  processing. 

A  status  message  indicates  one  or  more  of  several  radar  site  problems.  The  radar  sites  send  fixed  search  and 
fixed  beacon  test  messages  that  arc  examined  by  Non-Target  Processing  to  evaluate  equipment  and  site  per¬ 
formance.  The  messages  are  compared  with  correct  values  in  the  adaptation  ana  should  one  of  the  parame¬ 
ters  not  be  within  acceptable  tolerance,  a  test  message  error  is  output. 

If  a  jamming  report  is  issued  due  to  electromagnetic  counter  measures,  a  strobe  message  is  issued.  The 
strobe  information  notifies  the  computer  that  certain  azimuth  wedg.s  have  been  blanked  out  because  they 
were  completely  filled  by  some  interfering  signal  such  as  excess  fruit  or  interference  from  some  nearby  radar. 

1.1.4  Inputs 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  areas; 

•  JAMMED_RADAR_REPORTS  -  Radar  reports  that  are  declared  invalid  due  to  a  jamming  condition. 

1.1.4  Outputs 

•  RADAR_STROBE_MESSAGE  -  A  message  indicating  that  jamming  of  primary  or  secondary  radar  site 
data  is  in  effect  or  is  no  longer  in  effect; 

•  RADAR_TEST_STATUS_MESSAGES  -  A  test  or  status  message  received  from  a  radar  site  indicating 
equipment  status; 

•  WEATHER_MAP_MESSAGES  -  Weather  radar  messages  that  have  been  sent  with  the  traffic  radar. 
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1.1 .1.1  Digitize  Reports  Discussion 

Target  positions  are  determined  from  the  range  and  azimuth  from  the  radar  site,  and  are  provided  on  all 
detected  targets  by  search  and  beacon  radar.  The  resulting  analog  signals  are  digitized.  Radar  reports  are 
provided  by  both  the  primary  and  secondary  radar.  1.1. 1.1  DIGITIZE  REPORTS  is  shown  in  Figure  17 
on  page  42 

Primary  Radar  The  search  radar  ground  station  detects  aircraft,  ground  clutter,  and  weather  clutter  resulting 
from  reflection  of  signals  transmitted  from  the  ground  station. 

Secondary  Radar 

Secondary  radars  (beacon  radar)  provide  discrete  identity  and  altitude  reporting.  A  beacon  radar  ground 
station  detects  beacon  codes  from  aircraft  equipped  with  transponders  which  are  activated  upon  receipt  of 
interrogation  signal.  The  station  also  receives  pressure  altitude  data  from  all  aircraft  equipped  with  transpon¬ 
ders  capable  of  so  responding  to  Mode  C  interrogations. 

Mode  A  is  used  for  detection  and  identity.  Mode  C  is  used  for  requesting  altitude  information. 
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Figure  17.  1  1.1.1  DIGITIZE  REPORTS.  This  figure  illustrates  DIGITIZE  REPORTS  receiving  raw  reports  from 
the  PRIMARY  RADAR  and  the  SECONDARY  RADAR.  DIGITIZE  REPORTS  is  an  IOM  primitive. 
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1.1 .1.1  Inputs 

•  RAW_RADAR_REPORTS  -  Unprocessed  radar  returns  input  from  the  primary  radar; 

•  BEACON_DATA  -  Unprocessed  beacon  target  returns  from  the  secondary  radar. 

1.1 .1.1  Cutputs 

"  UNFILTERED_DIGITIZED_REPORTS  -  Digitized  radar  reports  that  have  come  from  good  radar 
sites,  failed  radar  sites,  and  jammed  radar  sites. 


I 
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1.2.1  Target  Data  Processing  Discussion 

TARGET  DATA  PROCESSING  object  shall  filter  out  all  FILTERED_TARGET_REPO  RTS  that  are  out 
of  the  boundaries  for  a  given  area  of  airspace,  and  route  the  remaining  FILTERED JTARGET_REPO  RTS 
to  children  objects  for  further  processing.  TARGET  DATA  PROCESSING  shall  normalize  data  collected 
from  multiple  radars  to  provide  consistent  information  about  a  given  target. 

TARGET  DATA  PROCESSING  is  illustrated  in  Figure  18  on  page  45. 
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1.2.1  Target  Filtering 

1 .2.1  Description 

The  TARGET  FILTERING  object  shall  accept  digitized  radar  data  and  discard  received  target  reports  from 
further  processing  when  these  reports  are  within  adapted  areas.  The  adapted  areas  shall  change  automatically 
when  facility  backup  is  invoked  and  shall  be  dependent  on  which  radar  is  being  backed  up. 

The  filter  shall  be  reconfigurable  to  account  for  failed  radar  sites.  The  reconfiguration  shall  be  initiated  by  a 
manual  input  from  the  monitor  and  control  console  or  automatically  when  a  radar  site  is  declared  to  have 
failed  by  the  radar  data  counting  function. 

Two  types  of  filtering  take  place  -  fixed  mapping  which  is  used  to  eliminate  coverage  in  geographic  areas  that 
are  not  needed  and  filtering  that  is  used  in  areas  of  multiple  surveillance  site  coverage  so  that  the  situation 
display  presents  only  a  single  target  symbol  per  aircraft. 

Surveillance  reports  shall  be  filtered  by  volumes  of  airspace.  A  preferred  radar  shall  be  adapted  for  each 
airspace  volume.  If  a  surveillance  report  on  a  aircraft  is  missing  from  the  preferred  radar,  then  a  report  from 
an  alternate  radar  shall  be  displayed  as  determined  by  adaptation. 

1.2.1  Inputs 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  areas; 

•  GEOGRAPHIC_DATA  •  Geographic  data  pertaining  to  center  boundary  definitions  used  for  filtering 
out  reports  outside  a  coverage  area. 

1.2.1  Outputs 

•  CENTER_FILTERED_TARGET_MSGS  -  Target  messages  that  pertain  to  a  given  center.  All  data 
not  pertinent  to  the  center  have  been  discarded. 

1.2.2  Radar  Data  Normalization 

1.2.2  Description 

RADAR  DATA  NORMALIZATION  involves  the  following  tasks: 

•  Collimation  Correction 

•  Coordinate  Conversion 

•  Altitude  Tracking 

•  Registration  Correction 

Collimation  Correction 

Collimation  is  the  process  of  detecting  the  misalignment  between  the  primary'  and  secondary  antennas.  A 
target's  Rho, 'Theta  data  for  search  radar  is  compared  with  that  of  beacon  radar  to  detect  collimation  errors. 
Collimation  error  corrections  are  recommended  to  the  system  engineer. 

Coordinate  Conversion 

Coordinate  conversion  transforms  data  from  polar  (Rho, Theta)  coordinates  to  system  coordinates.  Coordi¬ 
nate  conversion  cf  radar  data  is  needed  for  displays  which  require  x,y  coordinates  rather  than  Rho, Theta.  If 
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more  than  one  radar  is  supplying  data  to  a  display  or  to  an  automatic  tracking  program,  the  data  could  be 
converted  to  simple  x,y  with  a  common  reference  point.  Because  of  the  earth's  curvature  and  the  fact  that 
North  azimuth  lines  from  two  radars  not  on  the  same  longitude  are  not  parallel,  the  display  could  show  two 
returns,  and  the  tracking  program  could  have  difficulty  in  maintaining  a  single  track.  The  data  from  a  single 
track  must  have  the  same  system  coordinates  even  though  the  target  is  reported  from  different  radars.  The 
data  is  converted  to  a  common  system  plane.  The  most  common  method  of  converting  radar  position  data 
to  a  system  plane  is  to  use  a  stereographic  projection. 

Altitude  Tracking 

Altitude  tracking  shall  be  performed  on  paired  tracks  using  mode  C  altitudes  which  conform  to  operational 
requirements  for  mode  C  reasonableness  and  conformance  criteria. 

Registration  Correction  Registration  is  used  to  check  the  relative  alignment  between  radars  and  calculate  cor¬ 
rections  to  the  input  data.  These  corrections  can  then  be  applied  automatically  on  a  continuous  basis,  or  by 
the  system  engineer. 

This  analysis  involves  the  comparison  of  range  and  azimuth  data  from  different  radar  sites  on  the  same  target 
in  the  stereographic  plane  to  detect  errors  for  a  particular  site.  The  registration  error  message  is  sent  to  the 
system  engineer  for  a  site,  who  causes  correction  factors  to  be  applied  to  the  radar  data  (Rho/Theta)  from  a 
given  site. 

1.2.2  Inputs 

•  CENTER_FILTERED_TARGET_MSGS  -  Target  messages  that  pertain  to  a  given  center.  All  data 
not  pertinent  to  the  center  have  been  discarded. 

1.2.2  Outputs 

•  TRAFFIC_SURVEILLANCE_DISPLAY_DATA  -  Normalized  traffic  surveillance  data  is  sent  to  1.2 
TARGET  DATA  PROCESSING  for  processing  and  routing. 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  1.0  Traffic 
Surveillance. 

"All  Data  Flows"  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  flows  for  the  Traffic  Surveil¬ 
lance  object. 
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DATE:  28-APR-90 
TIME:  17:31 


hh  ALL  DATA  FLOWS  -  SURVEILLANCE  *«» 


RASE  1 
EXCEL/RTS 


Lane 

Alternate  Naee 

Short  Descrip. 

Last  Modify  Date 

J010I 

BAD  SITE  RADAR  DATA 

Radar  data  that  is  received  froa  a  radar  site  that  has  a 
failure  status.  The  data  is  discarded. 

891215 

J0073 

EEAC9N  DATA 

Unprocessed  beacon  taraet  returns  froa  the  secondary  radar. 

£91213 

JQ104 

CENTER  FILTERED  TARGET  HESS 

Tarqet  aessaqes  that  pertain  to  a  qiven  center.  All  date 
not  pertinent  to  the  center  nave  been  discarded. 

891215 

J0059 

DIGITIZED  RADAR  REPORTS 

Diqitized  radar  tarqets. 

891217 

J0095 

ENABLE  DISABLE  RADAR 

A  aessaqe  indicatinq  that  a  radar  sice  has  been  enabled  o- 
disabied.  The  aessaqe  includes  the  radar  id. 

291215 

J0071 

FILTERED  ’AR5ET  REPORTS 

Tarqet  Reports  that  have  been  filtered  to  only  have 
nonstationary  tarqets  froa  qood  sites  and  nonrestricted  area 

391217 

JO  104 

GE03RAFHIC  DATA 

Seoqraphic  data  pertaininq  :o  center  boundary  definitions. 

891214 

J0095 

JAMMED  RADAR  REPORTS 

Radar  reports  that  are  declared  invalid  due  to  a  jaaainq 
conciticn. 

891214 

J0100 

MILITARY  BEACON  CODES 

Beacon  codes  for  ailitary  aircraft. 

891215 

J0099 

MILITAFY  PRIMARY  RADAR  TARGETS 

Priaary  radar  returns  tnat  are  for  aihtary  aircraft. 

991215 

J0558 

PROCESSED  RADAR  REPORT'S 

Radar  tarqets  that  have,  been  filtered,  converted,  and 
corrected. 

391204 

J0090 

RADAR  FAILURE  NOTIFICATION 

Notification  of  the  failure  of  a  priaary  or  seccnaa-y  radar 
site. 

891215 

70059 

RADAR  RESET 

Notification  of  a  reset  of  a  priaary  or  secondary  radar 
site. 

891215 

JO  1=9 

RADAR  SITE  'AIL’JRE/RESET  REPORT 

Radar  action  raports  sent  to  RECORDING  SUPPORT  for  event 
ioqqinq  and  -‘urther  action.  Rpta  sent  upon  racar  state  chq. 

90C425 

J0079 

RADAS  SITE  FAILURE  REPORT 

Report  indicatinq  that  a  radar  site  has  failed.  Airway 
facilities  receives  this  data. 

891219 

RADAR  SI'E  FAILURE  RESET  REPORT 

A  report  of  a  faiiec  radar  site  or  a  resat  radar  sice  Co  :e 
ioqqed. 

PCJl-. 

J0f"5 

RADAR  STROBE  MESSAGE 

A  nessaqe  mdicatino  that  jasanq  cf  crinary  or  secondary 
raoar  site  dace  is  :  n  effect  or  is  ro  ionaer  in  effect. 

391214 

jo:o7 

=ADAR  TEST  STA'US  MESSAGES 

A  ceet  or  status  aessaee  reveiveo  froa  a  radar  site 
inoicatinq  equipeenc  status. 

391214 

70075 

.RAN  RAD-R  REPORTS 

Unorocessed  rada'  returns  input  froa  the  pnaarv  r=dar. 

891214 

*A>i  r.EA'^ER  =ADAR  REPORTS 

Unprocessed  weacner  radar  returns  input  ’’re?  weetrer  racar. 

39121!: 

DATE: 

TIDE: 

23-APR-90 

17:3! 
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PAGE  2 

EXCEL/RTS 

Nane 

Alternate  Naae 

Short  Descrip. 

Last  Modify  Date 

JO  103 

RESTRICTED  AREA  RADAR  DATA 

Radar  returns  froa  a  restricted  area  that  are  discarded. 

391215 

JO  1 02 

STATIONARY  TARGETS 

Stationary  radar  tarqets  that  are  discarded  as  non-tarqets. 

S912i5 

J0051 

TARGET  COUNTS 

A  count  of  the  radar  returns  for  a  radar  site. 

891213 

J0052 

TARGET  ERROR  COUNTS 

A  count  of  the  errors  in  the  radar  returns  for  a  radar 
site.  The  count  is  used  to  check  the  status  of  the  sites. 

S91218 

J0198 

TRACK  HISTGRY  UPDATES 

Aircraft  tarqet  track  messaqes  are  stored  in  the 

TRACK  HISTGRY  database  for  reference  by  other  ATC  subsysteas 

900425 

J0077 

TRAFFIC  INFORMATION 

An  inteqrated  view  of  the  air  traffic  presented  to  the 
controller. 

891204 

J0114 

TRAFFIC  3URVELLANCE  DATA 

Radar  surveillance  data  of  air  traffic  that  has  been 
noraalized  for  further  processinq  and  use  by  other  ATC  subsy 

900425 

J0110 

TRAFFIC  3URV  DISPLAY  DATA 

Normalized  traffic  surveillance  data. 

891214 

J0097 

UNFILTERED  BEACON  CODES 

Beacon  codes  that  have  coae  froa  qood  secondary  radar 
sites,  failed  sec.  radar  sites,  and  jaeaed  sec.  radar  sites. 

591213 

.  J0094 

) 

UNFILTERED  DIGITIZED  REPORTS 

Diqitized  radar  reports  that  have  coae  froa  qood  radar 
sites,  failed  radar  sites,  and  jaaaed  radar  sites. 

391215 

JO!  12 

HEATHER  DATA 

Heather  inforaaticn  oriqinatinq  froa  the  Real  Tiae  Heather 
Processor 

391214 

JO  105 

HEATHER  MAP  MESSAGES 

Heather  radar  aessaqes  that  have  beer,  sent  with  the  traffic 
radar. 

391217 

JOOS7 

HEATHES  SURV  DISPLAY  DATA 

An  inteqrated  view  of  weather  surveillance  info  converted 
to  polyqons  for  display. 

891217 

join 

HEATHER  SURV  INFO 

An  inteqrated  weather  surveillance  view. 

391217 
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"All  Data  Stores"  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  stores  for  the  Traffic  Sur¬ 
veillance  object.  1.0  Traffic  Surveillance  also  employs/derives/updates  the  following  globally  defined  data 
store,  defined  in  Appendix  A  of  this  document: 

•  TRACK_HISTORY. 
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DATE:  26-APR-90 
TIKE:  14:52 


*«  ALL  DATA  STORES  «* 
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EXCEL/RTS 


DATE:  ES-APR-90 
TIME:  14:52 


*»  ALL  DATA  STORES  «* 


PAGE  1 
EXCEL/RTS 


Nane  Alternate  Naae 


Long  Description 


1.1.2.  MILITARY  BEACON  CODES  The  MILITARY  BEACON  CODES  database  provides  the  1.1.2  RADAR  REPORT 

FILTER  with  silitary  beacon  code  ids.  This  enables  1.1. E  RADAR  REPORT 
FILTER  to  aask  tarqet  reports  Kith  certain  silitary  beacon  codes,  and 
to  add  inforaation  to  target  reports. 

1.1.2.  RADAR  COVERAGE  The  RADAR  COVERAGE  database  provides  the  1.1.2  RADAR  REPORT  FILTER  with 

radar  coveraqe  inforaation,  allowinq  it  to  filter  out  reports,  that  are 
outside  of  the  area  the  radar  is  responsible  to  report. 
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2.0  Weather  Surveillance 


Introduction  The  Weather  Surveillance  object  is  responsible  for  providing  weather  surveillance  information  to 
Area  Control  for  final  processing  to  display  an  integrated  view  of  air  traffic  and  weather  surveillance  informa¬ 
tion  to  air  traffic  controllers. 

The  WEATHER  SURVEILLANCE  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Weather  Surveillance  View  From 

•  The  Weather  Surveillance  Interfaces 

•  The  Weather  Surveillance  Functional  Object  Tree 

•  Weather  Surveillance. 

2.0  Weather  Surveillance  "View  From" 

The  DoD  AAS  Area  Control  view  from  2.0  WEATHER  SURVEILLANCE  is  illustrated  by  Figure  19  on 
page  51.  The  "view  from"  presents  all  of  the  major  functional  objects  of  the  DoD  AAS  Area  Control  and 
their  relationship  to  WEATHER  SURVEILLANCE  by  the  messages  that  are  passed  to  and  from  it. 

The  WEATHER  SURVEILLANCE  object  provides  weather  surveillance  information  to  Prediction  and 
Resolution,  Flight  Plan  Operations  Support,  and  Recording  Support.  It  provides  Weather  Surveillance 
Display  Data  to  Area  Control  for  further  processing  and  controller  presentation.  Finally,  Radar  Site 
Failure/Reset  Reports  are  sent  to  Recording  Support  for  logging. 
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Figure  19.  DoD  AAS  Area  Control  View  from  WEATHER  SURVEILLANCE.  This  figure  illustrates  the  view  of 
DoD  AAS  Area  Control  with  respect  to  WEATHER  SURVEILLANCE.  This  diagram  also  presents  all 
of  the  major  functional  objects  of  the  DoD  AAS  Area  Control  IOM  and  the  message  'pipes'  that  connect 
them  to  WEATHER  SURVEILLANCE. 
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2.0  Weather  Surveillance  Interfaces 

The  WEATHER  SURVEILLANCE  object  provides  weather  surveillance  information  to  Prediction  and 
Resolution,  Flight  Plan  Operations  Support,  and  Recording  Support.  It  provides  Weather  Surveillance 
Display  Data  to  Area  Control  for  further  processing  and  controller  presentation.  Finally,  Radar  Site 
Failure/Reset  Reports  are  sent  to  Recording  Support  for  logging.  Weather  data  is  provided  from  the  Real- 
Time  Weather  Processor  and  the  Weather  surveillance  radars.  Weather  front  map  messages  are  received 
from  Traffic  Surveillance  radars  to  augment  the  Weather  surveillance  radars. 

The  interfaces  to  WEATHER  SURVEILLANCE  are  illustrated  on  Figure  20  on  page  53. 
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2.0  WEATHER  SURVEILLANCE  INTERFACES 


1.0  TRAFFIC 
SURVEILLANCE 


8.0  AREA 
CONTROL 


3.0  PREDICTION 
&  RESOLUTION 

7.0  FLIGHT 

PLAN  OPERATIONS 

SUPPORT 

4.0  RECORDING 
SUPPORT 


Figure  20.  Interfaces  for  2.0  WEATHER  SURVEILLANCE.  This  figure  illustrates  the  interfaces  of  the  the  2.0  . 

WEATHER  SURVEILLANCE  functional  object.  This  diagram  shows  the  major  inputs  from  other  DoD 
AAS  Area  Control  functional  objects  and  external  interfaces. 
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2.0  Weather  Surveillance  Inputs 

•  WEATHER_MAP_MESSAGES  -  Weather  radar  messages  that  have  been  provided  from  the  traffic 
2.0  Weather  Surveillance  Outputs 

•  WEATHER_SURV_DISPLAY_DATA  -  An  integrated  view  of  weather  surveillance  info  converted  to 
polygons  for  display; 

•  WEATHER_SURV_INFO  -  An  integrated  weather  surveillance  view. 

2.0  Weather  Surveillance  Functional  Object  Tree 

The  functional  object  tree  for  2.0  WEATHER  SURVEILLANCE  presents  the  object  hierarchy  of 
WEATHER  SURVEILLANCE,  as  illustrated  in  Figure  12  on  page  29  The  functional  object  tree  presents 
all  of  the  graphics  used  to  describe  WEATHER  SURVEILLANCE,  as  well  as  fhe  message  communication 
paths  that  show  communication  between  peer  objects,  parent  objects  to  child  objects,  and  child  to  parent 
objects;  It  also  identifies  the  communication  paths  between  the  decomposition  levels. 
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2.0  WEATHER  SURVEILLANCE  FUNCTIONAL  OBJECT  TREE 
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Figure  21.  Functional  Object  Tree  for  2.0  WEATHER  SURVEILLANCE.  This  figure  illustrates  the  functional 
object  tree  for  the  WEATHER  SURVEILLANCE  functional  object.  This  tree  shows  the  hierarchic 
rclauonship  between  the  subordinate  functional  objects  and  shows  message  passing  between  peer  objects, 
parent  objects  and  child  objects  on  different  levels. 
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2.0  Weather  Surveillance  Discussion 

The  purpose  of  WEATHER  SURVEILLANCE  is  to  present  to  air  traffic  controllers  a  consistent  view  of 
weather  conditions  in  a  given  sector  of  airspace.  This  view  of  weather  conditions  is  provided  from  raw 
sensor  data  collected  from  both  the  primary  traffic  surveillance  radars  and  single-purpose  weather  radars  and 
processed  to  filter  and  present  radar  information  about  weather  to  air  traffic  controllers  in  the  form  of  map 
overlays  on  the  display  console(s).  Weather  information  is  also  provided  to  WEATHER  SURVEILLANCE 
from  the  FAA  realtime  weather  processor,  located  in  in  Kansas  City,  which  collects  weather  information 
from  all  various  weather  data  sources.  WEATHER  SURVEILLANCE  is  illustrated  in  Figure  22  on 
page  57. 
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Figure  22.  2.0  WEATHER  SURVEILLANCE.  This  figure  illustrates  WEATHER  SURVEILLANCE  and  its  chil- 
urcn  objects  2.1  WEATHER  RADAR  SUPERVISOR  and  2.2  WEATHER  DATA  PROCESSING. 
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2.1  Weather  Radar  Supervisor 

2.1  Description 

The  WEATHER  RADAR  SUPERVISOR  object  shall  examine  radar  data  from  designated  weather  radar 
sites  to  determine  radar  failures.  Any  radar  failures  found  sh  je  logged  for  review  by  Airway  Facilities  to 
take  the  appropriate  corrective  action.  Airway  Facilities  wk  surne  all  responsibilities  for  equipment  main¬ 
tenance  and  repair.  Further,  upon  error  discovery,  the  WEA.'HER  RADAR  SUPERVISOR  shall  declare 
the  suspect  radar  invalid  and  shall  issue  instructions  for  reports  from  the  invalid  radar  to  be  filtered  out. 
Counts  provided  from  the  RADAR  DATA  COUNTING  object  are  analyzed  to  determine  if  there  are 
excessive  or  missing  types  of  targets  and  to  declare  a  site  with  missing  or  excessive  targets  or  errors  as  a  failed 
radar  site.  Finally,  the  WEATHER  RADAR  SUPERVISOR  shall  provide  a  message  routing  function 
taking  the  basic  filtered  target  reports  received  and  forward  them  to  TARGET  DATA  PROCESSING  for 
further  processing. 

2.1  Inputs 

•  ENABLE_DISABLE_RADAR  -  A  message  indicating  that  a  radar  site  has  been  enabled  or  disabled. 
The  message  includes  the  radar  id; 

•  RADAR_TEST_STATUS_MESSAGES  -  A  test  or  status  message  reveived  from  a  radar  site  indicating 
equipment  status; 

•  TARCET_COUNTS  -  A  count  of  the  radar  returns  for  a  radar  site; 

•  TARGET_ERROR_COUNTS  -  A  count  of  the  errors  in  the  radar  returns  for  a  given  radar  site.  The 
count  is  used  to  check  the  status  of  the  sites; 

•  DIGITIZED_RADAR_REPORTS  -  Digitized  radar  targets. 

2.1  Outputs 

•  DIGITIZED_RADAR_REPORTS  -  Digitized  radar  targets  forwarded  to  2.2  WEATHER  TARGET 
PROCESSING; 

•  RADAR_SITE_FAILURE_REPORT  -  Report  indicating  that  a  radar  site  has  failed.  Airway  Facilities 
receives  this  data; 

•  RADAR_RESET  -  Notification  of  a  reset  of  a  primary  or  secondary  radar  site; 

•  RADAR_FAILURE_NOTIFICATION  -  Notification  of  the  failure  of  a  primary  or  secondary  radar 
site; 


2.2  Weather  Target  Processing 

2.2  Description 

The  WEATHER  TARGET  PROCESSING  object  shall  filter  out  all  1  ILTERED_TARGET_REPORTS 
that  are  out  of  the  boundaries  lor  a  given  area  of  airspace,  and  route  the  remaining 
FILTERED_TARGET_REPORTS  to  children  objects  for  further  processing.  WEATHER  TARGET 
PROCESSING  shall  normalize  data  collected  from  multiple  radars  to  provide  consistent  information  about 
the  weather. 
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2.2  Inputs 

•  DIGITIZED  RADAR  REPORTS  -  Digitized  radar  targets  forwarded  from  2.1  WEATHER  RADAR 
SUPERVISOR; 

•  WEATHER_DATA  -  Weather  information  originating  from  the  Real  Time  Weather  Processor; 

•  WEATHER_MAP_MESSAGES  -  Weather  radar  messages  that  have  been  sent  with  the  traffic  radar. 

2.2  Outputs 

•  WEATHER_SURV_INFO  -  An  integrated  weather  surveillance  view  prepared  for  surveillance  view 
integration  processing. 
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2.1  Weather  Radar  Supervisor  Discussion 

The  WEATHER  RADAR  SUPERVISOR  object  shall  examine  radar  data  from  weather  radar  sites  to 
determine  radar  failures.  Any  radar  failures  found  shall  be  logged  for  review  by  Airway  Facilities  to  take  the 
appropriate  corrective  action.  Airway  Facilities  will  assume  all  responsibilities  for  equipment  maintenance 
and  repair.  Further,  upon  error  discovery,  the  WEATHER  RADAR  SUPERVISOR  shall  declare  the 
suspect  radar  invalid  and  shall  issue  instructions  for  reports  from  the  invalid  radar  to  be  filtered  out.  Counts 
provided  from  the  RADAR  DATA  COUNTING  object  are  analyzed  to  determine  if  there  are  excessive  or 
missing  types  of  targets  and  to  declare  a  site  with  missing  or  excessive  targets  or  errors  as  a  failed  radar  site. 
Finally,  the  RADAR  SUPERVISOR  shall  provide  a  message  routing  function  taking  the  basic  filtered  target 
reports  received  and  forward  them  to  TARGET  DATA  PROCESSING  for  further  processing.  2.1 
WEATHER  RADAR  SUPERVISOR  is  illustrated  in  Figure  23  on  page  61.  The  state  transition  diagram 
illustrating  the  behavior  of  RADAR  SUPERVISOR  given  radar  status  is  illustrated  in  Figure  24  on 
page  62. 
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Figure  23.  2.1  WEATHER  RADAR  SUPERVISOR.  This  figure  illustrates  WEATHER  RADAR  SUPERVISOR 
and  its  children  objects,  2.1.1  RADAR  COUNTING,  2.1.2  RADAR  REPORT  FILTER,  2.1.3  ECM 
DETECTOR,  2.1.4  NON-TARGET  DATA  PROCESSING. 
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Figure  24.  2.1  WEATHER  RADAR  SUPERVISOR  BEHAVIOR.  This  figure  illustrates  the  state  transition 
diagram  for  changing  between  three  states,  namely:  RADAR  ONLINE,  RADAR  INVALID,  and 
RADAR  OFFLINE. 
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2.1.1  Radar  Counting 

2.1 .1  Description 

The  RADAR  COUNTING  object  shall  examine  radar  counts  to  ascertain  excesses  or  failures  in  radar  data 
received  iom  reporting  radar  sites.  Counts  shall  be  maintained  for  number  of  targets  and  target  errors 
receiv-u  from  each  radar  site. 

2.1.1  Inputs 

•  DIGITIZED  RADAR  REPORTS  -  Digitized  radar  targets  received  from  2. 1.1.1  DIGITIZE 
REPORTS.  “ 

2.1 .1  Outputs 

•  TARGET_COUNTS  -  A  count  of  the  radar  returns  for  a  radar  site; 

•  TARGET_ERROR_COUNTS  -  A  count  of  the  errors  in  the  radar  returns  for  a  radar  site.  The  count 
is  used  to  check  the  status  of  the  sites. 

2.1.2  Radar  Report  Filter 

2.1.2  Description 

The  RADAR  REPORT  FILTER  object  shall  reduce  the  number  of  radar  returns  to  be  processed.  Radar 
returns  shall  be  discarded  if  they  are  received  from  failed  radar  sites. 

Masking  is  the  process  of  filtering  radar  data  by  area,  and  is  used  to  reduce  the  number  of  radar  returns  to  be 
processed  by  the  remaining  subprograms.  Areas  with  more  than  double  radar  coverage  are  considered  for 
masking,  which  is  applied  selectively  on  a  Rho, Theta  basis  for  each  radar.  The  mask  for  each  radar  is  con¬ 
trolled  by  the  adaptation  parameters  which  is  used  to  compensate  for  radar  failures. 

The  state  transition  digram  describing  the  behavior  of  the  RADAR  REPORT  FILTER  object  for  transi¬ 
tioning  between  radar  validity  states  is  depicted  in  Figure  25  on  page  65. 

2.1.2  Inputs 

•  DIGITIZED  RADAR  REPORTS  -  Digitized  radar  targets  received  from  2. 1.1.1  DIGITIZE 
REPORTS 

•  RADAR_RESET  -  Notification  of  a  reset  of  a  primary  or  secondary  radar  site; 

•  RADAR_FAILURE_NOTIFICATION  -  Notification  of  the  failure  of  a  primary  or  secondary  radar 
site; 

•  JAMMED_RADAR_REPORTS  -  Radar  reports  that  are  declared  invalid  due  to  a  jamming  condition. 

•  RADAR_COVERAGF,  (DATA  STORE)  -  to  provide  radar  coverage  data  for  center,  for  filtering  pur¬ 
poses. 

2.1.2  Outputs 

•  BAD_SITE_RADAR_DATA  -  Radar  data  that  is  received  from  a  radar  site  that  has  a  failure  status. 

The  data  is  discarded; 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  area. 
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changing  between  two  states,  namely:  RADAR  VALID  and  RADAR  INVALID. 
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2.1.3  ECM  Detection 

2.1.3  Description 

The  ECM  DETECTOR  object  shall  identify  radar  returns  that  have  originated  in  ah  area  which  is  being 
jammed  by  electromagnetic  counter  measures. 

2.1.3  Inputs 

•  DIGITIZED  RADAR  REPORTS  -  Digitized  radar  targets  received  from  2.1.1.1  DIGITIZE 
REPORTS.  “ 

2.1.3  Outputs 

•  JAMMED_RADAR_REPORTS  -  Radar  reports  that  are  declared  invalid  due  to  a  jamming  condition. 

2.1.4  Non-Target  Data  Processing 

2.1.4  Description 

Non-target  as  well  as  target  messages  are  received  from  the  primary  and  secondary  radar  sites.  Non-Target 
Processing  monitors  the  test  and  status  messages,  generates  a  strobe  message,  and  forwards  the  map  messages 
to  weather  surveillance  processing. 

A  status  message  indicates  one  or  more  of  several  radar  site  problems.  The  radar  sites  send  fixed  search  and 
fixed  beacon  test  messages  that  are  examined  by  Non-Target  Processing  to  evaluate  equipment  and  site  per¬ 
formance.  The  messages  are  compared  with  correct  values  in  the  adaptation  and  should  one  of  the  parame¬ 
ters  not  be  within  acceptable  tolerance,  a  test  message  error  is  output. 

If  a  jamming  report  is  issued  due  to  electromagnetic  counter  measures,  a  strobe  message  is  issued.  The 
strobe  information  notifies  the  computer  that  certain  azimuth  wedges  have  been  blanked  out  because  they 
were  completely  filled  by  some  interfering  signal  such  as  excess  fruit  or  interference  from  some  nearby  radar. 

2.1.4  Inputs 

•  JAMMED_RADAR_REPORTS  -  Radar  reports  that  are  declared  invalid  due  to  a  jamming  condition; 

•  FILTERED_TARGET_REPORTS  -  Target  Reports  that  have  been  filtered  to  only  have  nonstationary 
targets  from  good  sites  and  nonrestricted  area. 

2.1.4  Outputs 

•  RADAR_STROBE_MESSAGE  -  A  message  indicating  that  jamming  of  primary  or  secondary  radar  site 
data  is  in  effect  or  is  no  longer  in  effect; 

•  RADAR_TEST_STATUS_MESSAGES  -  A  test  or  status  message  reveived  from  a  radar  site  indicating 
equipment  status. 
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2.1 .1.1  Digitize  Weather  Reports  Discussion 

Target  positions  are  determined  from  the  range  and  azimuth  from  the  radar  site,  and  are  provided  on  all 
detected  targets  by  search  and  beacon  radar.  The  resulting  analog  signals  are  digitized.  Radar  reports  are 
provided  by  both  the  primary  and  secondary  radar.  2.1.1. 1  DIGITIZE  WEATHER  REPORTS  is  shown  in 
Figure  26  on  page  68 

Primary  Radar  The  search  radar  ground  station  detects  aircraft,  ground  clutter,  and  weather  clutter  resulting 
from  reflection  of  signals  transmitted  from  the  ground  station. 
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2.1.1  RADAR  COUNTING 

2.1.2  RADAR  REPORT  FILTER 

2.1.3  ECU  DETECTOR 


Note:  This  Is  ,i  service  machine  that, 
proviocs  ojls  t-o  the  (ol lowing: 

2.1.1  RADAR  COUNTING 

2.1.2  RADAR  RKPOK1  FILTER 

2.1.3  LCM  DETECTOR 


Figure  26.  2.1. 1.1  DIGITIZE  WEATHER  REPORTS.  This  figure  illustrates  DIGITIZE  WEATHER  REPORTS 
receiving  raw  reports  from  the  PRIMARY  RADAR  and  the  SECONDARY  RADAR.  DIGITIZE 
WEATHER  REPORTS  is  an  IOM  primitive. 
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2.1 .1.1  inputs 

•  RAW  WEATHER  RADAR  REPORTS  -  Raw  radar  reports  produced  from  the  WEATHER 
RADAR(s). 

2.1 .1 .1  Outputs 

•  UNFILTERED_DIGITIZED_REPORTS  -  Digitized  radar  reports  that  have  come  from  good  radar 
sites,  failed  radar  sites,  and  jammed  radar  sites. 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  2.0  Weather 
Surveillance. 

"All  Data  Flows"  Report 

Refer  to  the  data  flows  section  presented  in  1.0  Traffic  Surveillance. 

"All  Data  Stores"  Report 

Refer  to  the  data  stores  section  presented  in  1.0  Traffic  Surveillance.  Appendix  A  provides  a  report  of 
globally  defined  data  stores  available  to  all  functional  objects. 
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3.0  Prediction  and  Resolution 

Introduction 

The  Prediction  and  Resolution  Major  Functional  Object  predicts  and  resolves  conflicts,  whether  aircraft  to 
aircraft  conflicts,  or  aircraft  to  ground  conflicts. 

The  PREDICTION  AND  RESOLUTION  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Prediction  and  Resolution  View  From 

•  The  Prediction  and  Resolution  Interfaces 

•  The  Prediction  and  Resolution  Functional  Object  Tree 
'  Prediction  and  Resolution. 

3.0  Prediction  and  Resolution  "View  From" 

The  Prediction  and  Resolution  object,  shown  in  Figure  27  on  page  72,  acts  upon  surveillance  data  and 
flight  plan  data  to  predict  and  resolve  imminent  and  future  conflicts.  It  receives  Traffic  Surveillance  Data 
from  1.0  Traffic  Surveillance.  Although  it  uses  the  Flight  Plan  data  store  in  it's  predictions,  new  or  updated 
flight  plans  are  passed  from  7.0  Flight  Plan  Operations  Support,  to  be  checked  for  future  conflicts.  Returned 
to  7.0  are  any  identified  Conflict  Situations.  Prediction  and  Resolution  also  uses  Weather  Surveillance  Infor¬ 
mation,  passed  from  2.0  Weather  Surveillance.  Conflict  Resolution  Requests  may  be  submitted  by  the  8.0 
Area  Control  and  8.0  constantly  receives  the  latest  conflict  Analysis  Results  Display.  Prediction  and  Resol¬ 
ution  also  uses  data  stores  Airport  and  Airport  Status,  Aircraft  and  Environment  Data,  and  Track  History 
Data.  It  logs  any  pertinent  information  by  sending  Analysis  Log  to  4.0  Recording  Support. 
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Figure  27.  DoD  AAS  View  From  Prediction  and  Resolution.  This  figure  highlights  the  Prediction  and  Resolution 


functional  object  and  shows  the  flow  of  information  to  and  from  the  other  functional  objects  in  the  DoD 


AAS  ATC  Model. 
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3.0  Prediction  and  Resolution  Interfaces 

The  interfaces  to  3.0  Prediction  and  Resolution  are  shown  in  Figure  28  on  page  74.  It  receives  Traffic  Sur¬ 
veillance  Data,  which  it  passes  on  to  3.1  Tactical  Prediction.  It  receives  Resolution  Requests,  which  it 
passes  on  to  3.4  Strategic  Resolution.  It  receives  Flight  Plan  Changes,  which  it  passes  on  to  3.3  Strategic 
Prediction. 
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3.0  PREDICTION  &  RESOLUTION  INTERFACES 


1.0  SURVEILLANCE 


TRAFFIC 

SURVEILLANCE 

DATA 


8.0  AREA  CONTROL 


RESOLUTION 

REQUESTS 


3.0 

PREDICTION  & 
RESOLUTION 


7.0  FLIGHT  PLAN  OPERATIONS 


FLIGHT  PLAN 
CHANGES 


RESOLUTION 

REQUESTS 


3.4  STRATEGIC  RESOLUTION 


FLIGHT  PUN 
CHANGES 


TRAFFIC 

SURVEILUNCE 

DATA 


3.3  STRATEGIC  PREDICTION 


3.1  TACTICAL  PREDICTION 


Figure  28.  Prediction  and  Resolution  Interfaces.  This  figure  shows  the  interfaces  with  the  Prediction  and  Resolution 
functional  object,  and  the  other  functional  objects  of  the  DoD  AAS  ATC  Model. 


3.0  Prediction  and  Resolution  Inputs 
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•  FLIGHT_PLAN_CHANGES  -  A  flight  plan  whose  status  has  changed.  It  may  have  been  initiated, 
amended,  or  initialized  (flight  departed). 

•  RESOLUTION_REQUESTS  -  Requests  from  the  controller  for  resolutions  to  near-term,  but  not 
immediate,  problems  (e.g.  flight  plan  non  conform). 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

2.0  Prediction  and  Resolution  Outputs 

•  FLIGHT_PLAN_CHANGES  -  A  flight  plan  whose  status  has  changed.  It  may  have  been  initiated, 
amended,  or  initialized  (flight  departed). 

•  RESOLUTION_REQUESTS  -  Requests  from  the  controller  for  resolutions  to  near-term,  but  not 
immediate,  problems  (e.g.  flight  plan  non  conform). 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

3.0  Prediction  and  Resolution  Functional  Object  Tree 

The  functional  object  tree  identifies  the  communication  paths  between  the  functional  objects  in  the  Predic¬ 
tion  and  Resolution  process. 

Figure  29  on  page  76  shows  the  Functional  Object  Tree. 
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3.0  CONTROL  FUNCTIONAL  OBJECT  TREE 


3.4  OIAGRAM 


Figure  29.  3  0  Prediction  and  Resolution  Functional  Object  Tree.  This  figure  illustrates  the  functional  object  tree  for 
the  Prediction  and  Resolution  Functional  Object. 
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3.0  Prediction  and  Resolution  Discussion 

The  Prediction  and  Resolution  object,  shown  in  Figure  30  on  page  78,  passes  the  following  data: 

•  Surveillance  (radar)  data  to  Tactical  Prediction  to  determine  if  there  are  airspace  conflicts  and  provide 
any  need  maneuvers. 

•  Flight  Plan  Updates  to  Strategic  Prediction  to  predict  future  airspace  conflicts. 

•  Resolution  requests  to  Strategic  Resolution  to  find  controller  requested  resolutions  to  in-flight,  but  not 
immediate,  problems. 
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3.1  Tactical  Prediction 

3.1  Description 

The  Tactical  Prediction  object  passes  aircraft  surveillance  data  to  be  used  to  predict  real-time  conflicts  (air¬ 
craft  to  aircraft  and  minimum  safe  altitude).  If  accepts  resulting  Alert  Data  and  passes  it  to  the  Tactical 
Resolution  object  to  generate  a  list  of  potential  evasive  maneuvers. 

3.1  Inputs 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

3.1  Outputs 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

3.2  Tactical  Resolution 

3.2  Description 

The  Tactical  Resolution  object  accepts  alert  data  from  the  Tactical  Prediction  function  to  be  used  to 
compute  up  to  4  evasive  maneuvers  to  be  presented  to  the  controller  in  order  to  resolve  the  alert/conflict. 

i 

3.2  Inputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

3.2  Outputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

3.3  Strategic  Prediction 

3.3  Description 

The  Strategic  Prediction  object  passes  on  flight  plan  changes  (and  calculated  resolutions  from  Strategic 
Resolution)  to  be  evaluated  to  determine  if  any  in-flight  conflicts  will  arise,  such  as  aircraft  to  aircraft  con¬ 
flicts,  aircraft  to  special-use  airspace  violations,  or  flow  control  constraint  violations. 

3.3  Inputs 

•  FLIGHT_PLAN_CHANGES  -  A  flight  plan  whose  status  has  changed.  It  may  have  been  initiated, 
amended,  or  initialized  (flight  departed). 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 
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3.3  Outputs 

•  FLIGHT_PLAN_CHANGES  -  A  flight  plan  whose  status  has  changed.  It  may  have  been  initiated, 
amended,  or  initialized  (flight  departed). 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 

3.4  Strategic  Resolution 

3.4  Description 

The  Strategic  Resolution  object  accepts  resolution  requests  from  the  controller  in  3  forms:  delay  request, 
resolution  request,  and  reconformance  request.  If  finds  resolutions  to  these  requests  which  are  passed  on  to 
the  Strategic  Prediction  object  to  look  for  potential  conflicts. 

3.4  Inputs 

•  RESOLUTION_REQUESTS  -  Requests  from  the  controller  for  resolutions  to  near-term,  but  not 
immediate,  problems  (e.g.  flight  plan  non  conform). 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 

3.4  Outputs 

•  DELAY_REQUEST  -  Request  from  controller  to  delay  an  aircraft's  progress  in  order  to  avoid  over¬ 
crowding  at  specific  places. 

•  RECONFORMANCE_REQUEST  -  Request  from  the  controller  for  aid  in  bringing  a  strayed  flight 
back  into  conformance  with  its  flight  plan. 

•  RESOLUTION_REQUEST  -  Request  from  the  controller  for  aid,  in  the  form  of  potential  solution,  in 
resolving  an  identified  conflict. 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 
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■'v  3.1  Tactical  Prediction  Discussion 

y 

The  3.1  Tactical  Prediction  function  passes  on  Traffic  Surveillance  Data  to  3.1.1  Time/Position  Calculation 
which  predicts  aircraft  positions  minutes  into  the  future.  This  data  is  used  to  identify  potential  conflicts. 
The  children  of  3.1  Tactical  Prediction  are  shown  in  Figure  31  on  page  82. 
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Figure  31.  3.1  Tactical  Prediction  DFD.  This,  figure  is  the  data  Oow  diagram  for  the  iOM  Object,  3.1  Tactical  Pre¬ 
diction. 
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3.1.1  Time/Position  Calculation 

3.1.1  Description 

The  Time/Position  calculation  object  performs  the  following: 

•  For  an  established  length  of  time  (e.g.  S  minutes),  this  object  steps  through  incrementally  (e.g.  every  10 
seconds)  to  produce  a  new  predicted  picture  of  the  track  positions.  The  prediction  is  based  on  the 
aircraft/track's  past  behavior  or  track  history. 

•  Each  incremental  picture  is  passed  on  to  3.1.2  (Compare  Aircraft  to  Aircraft)  and  3.1.4  (Compare  Air- . 
craft  to  Ground)  to  assess  conflicts. 

Weather  Data  is  also  examined  when  determining  a  track's  future  path. 

3.1.1  Inputs 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

•  ALERT_DATA  •  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

•  WEATHER_SURV_INFO  -  Weather  information  in  the  form  of  radar  data  and  reports  on  pressure, 
winds  aloft,  temperature,  etc. 

3.1.1  Outputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  of  known  aircraft  tracks 
based  on  previous  track  history. 

3.1.2  Compare  Aircraft  to  Aircraft 

3.1.2  Description 

For  each  predicted  picture  sent  to  it  by  Time/Position  Calculation  object,  the  Compare  Aircraft  to  Aircraft 
object  searches  aircraft  by  '  -craft  for  potential  collisions.  The  distances  between  all  aircraft  are  measured 
and  compared  to  separation  standards,  contained  in  the  Rules  and  Regulations  data  store.  If  any  conflicts 
are  found,  the  ALERT  DATA  is  passed  to  the  Alert  Processing  object. 

3.1 .2  Inputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  of  known  aircraft  tracks 
based  on  previous  track  history. 

3.1.2  Outputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  rn  aircraft  and 
the  ground. 

3.1.3  Alert  Processing 

3.1.3  Description 

The  alert  processing  object  accepts  ALERT  DATA  from  3.1.2  Compare  Aircraft  to  Aircraft  and  3.1.4 
Compare  Aircraft  to  Ground.  It  assesses  the  alert  for  severity  and  passes  the  ALERT  DATA  to  8.0  Arcs 
Control  and  4.0  Recording  Support.  It  also  routes  the  ALERT  DATA  to  3.1  Tactical  Prediction. 
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3.1.3  Inputs 

•  ALERT_DATA  •  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

3.1.3  Outputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

•  ALERT_DISPLAY_DATA  -  Data  sent  by  the  TACTICAL  PREDICTION  function  to  the  controller 
to  notify  of  identified  conflicts  or  alerts. 

3.1.4  Compare  Aircraft  to  Ground 

3.1.4  Description 

For  each  predicted  picture  sent  by  3.1.1  Time/Position  Calculation,  the  3.1.4  Compare  Aircraft  to  Ground 
object  compares  the  predicted/current  altitude  of  each  aircraft  to  established  minimum  standards  (given  in 
the  Rules  and  Regulations  data  store).  If  these  standards  are  violated,  it  sends  alert  data  to  3.1.3  Alert  proc¬ 
essing. 

3.1.4  Inputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  of  known  aircraft  tracks 
based  on  previous  track  history. 

3.1.4  Outputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 
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3.2  Tactical  Resolution  Discussion 

The  3.2  Tactical  Resolution  object  receive  alert  data  from  3.1.1  Tactical  Prediction,  which  it  uses  to  resolve 
conflicts  by  generating  possible  evasive  maneuvers.  The  children  of  3.2  Tactical  Resolution  are  shown  in 
Figure  32  on  page  86. 
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Figure  32.  3.2  Tactical  Resolution  DFD.  This  figure  is  the  data  flow  diagram  for  the  IOM  Object,  3.2  Tactical 
Resolution. 
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3.2.1  Classify  Conflict 

3.2.1  Description 

The  Classify  Conflict  object  assesses  the  conflict  passed  to  it  by  3 2  Tactical  Resolution  (generated  by  3.1 
Tactical  Prediction).  The  classification  are  in  the  form  of  Warning,  Serious,  or  Critical. 

3.2.1  Inputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

3.2.1  Outputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

•  ALERT_CLASSIFICATION  •  Classification  of  the  alert  as  Warning,  Serious,  or  Critical. 

3.2.2  Generate  Evasive  Mctneuvers 

3.2.2  Description 

The  Generate  Evasive  Maneuver  object  uses  a  complex  algorithm  to  generate  potential  maneuvers  to  be 
communicated  by  the  controller  to  a  pilot  in  order  to  avoid  an  imminent  conflict  (collision  with  another 
aircraft  or  the  ground).  These  maneuvers  include  turns,  climbs,  descends,  increase/decrease  power,  or  a  com¬ 
bination  of  these. 

3.2.2  Inputs 

•  ALERT_DATA  -  Data  describing  a  conflict  between  an  aircraft  and  another  aircraft  or  an  aircraft  and 
the  ground. 

•  ALERT_CLASSIFICATION  -  Classification  of  the  alert  as  Warning,  Serious,  or  Critical. 

3.2.2  Outputs 

•  EVASIVE_MANEUVERS  -  Maneuvers  generated  to  avoid  imminent  conflict.  Composed  of  turns, 
acceleration/decelerations,  altitude  changes. 
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3.3  Strategic  Prediction  Discussion 

The  3.3  Strategic  Prediction  object  receives  Flight  Plan  Changes  from  3.0  Prediction  and  Resolution  and 
Calculated  Resolutions  from  3.4  Strategic  Resolution  which  it  passes  down  to  3.3.1  Time/Position  Calcu¬ 
lation.  3.3.1  models  aircraft  and  airspace  into  the  future  and  passes  predicted  data  to  be  checked  for  con¬ 
flicts.  The  children  of  3.3  Strategic  Prediction  are  shown  in  Figure  33  on  page  89. 


3.0  Prediction  and  Resolution 


87 


STARS  Deliverable  1200 


Prediction. 
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3.3.1  Time/Position  Calculation 

3.3.1  Description 

The  Time/Position  Calculation  object  will  incrementally  produce  predicted  positions  of  aircraft  based  on 
flight  plan  and  the  passed  flight  plan  change  data.  The  prediction  process  also  examines  weather  data  and 
aircraft  characteristics  to  predict  future  positions.  These  incremental  pictures  are  output  to  be  examined  for 
conflicts:  aircraft  to  aircraft,  aircraft  to  airspace;  and  for  flow  control  constraint  violations. 

3.3.1  Inputs 

•  FLIGHT_PLAN_CHANGES  -  A  flight  plan  whose  status  has  changed.  It  may  have  been  initiated, 
amended,  or  initialized  (flight  departed). 

•  CALCULATED_RESOLUTION  *  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 

•  WEATHER_SURV_INFO  -  Weather  information  in  the  form  of  radar  data  and  reports  on  pressure, 
winds  aloft,  temperature,  etc. 

3.3.1  Outputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  n' known  aircraft  tracks 
based  on  previous  track  history. 

3.3.2  Compare  Aircraft  to  Aircraft 

3.3.2  Description 

The  Compare  Aircraft  to  Aircraft  object  examines  the  predicted  position  of  aircraft  at  a  particular  time,  as 
generated  by  3.3.1  Time/Position  Calculation.  It  compares  every  aircraft's  position  to  every  other  aircraft's 
position  and  checks  against  separation  standards  contained  in  Rules  and  Regulations  data  store.  If  the  sepa¬ 
ration  is  less  than  the  standard,  a  conflict  situation  record  is  generated  and  sent  to  3.3.3  Alert  Processing. 

3.3.2  Inputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  of  known  aircraft  tracks 
based  on  previous  track  history. 

3.3.2  Outputs 

•  CONFLICT_SITUATION_DATA  -  Data  concerning  a  particular  conflict  which  has  been  identified. 

3.3.3  Alert  Processing 

3.3.3  Description 

The  Alert  Processing  object  receives  alerts  from  3.3.2  Compare  Aircraft  to  Aircraft,  3.3.4  Compare  Aircraft 
to  Airspace,  and  3.3.5  Check  Flow  restrictions.  It  classifies  the  alert  and  generates  conflict  data  for  the  con¬ 
troller,  Recording  Support,  and  3.3  Strategic  Prediction. 

3.3.3  Inputs 

•  CONFLICT_SITUATION_DATA  -  Data  concerning  a  particular  conflict  which  has  been  identified. 
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3.3.3  Outputs 

•  CONFLICT_SITUATION_DATA  -  Data  concerning  a  particular  comlict  which  has  been  identified. 

•  ALERT_DISPLAY_DATA  -  Data  sent  by  the  TACTICAL  PREDICTION  function  to  the  controller 
to  notify  of  identified  conflicts  or  alerts. 


3.3.4  Compare  Aircraft  to  Airspace 

3.3.4  Description 

The  Compare  Aircraft  to  Airspace  object  examines  the  predicted  positions  of  aircraft  as  passed  to  it  by  3.3. 1 
Time/Position  Calculation.  Each  aircraft's  position  is  examined  to  see  if  it  violates  any  special  use  airspace 
restriction.  If  a  violation  is  found,  it  is  sent  in  the  form  of  conflict  situation  data  to  3.3.3  Alert  Processing. 

3.3.4  Inputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  of  known  aircraft  tracks 
based  on  previous  track  history. 

3.3.4  Outputs 

•  CONFLICT_SITLATION_DATA  -  Data  concerning  a  particular  conflict  which  has  been  identified. 

3.3.5  Check  Flow  Restriction 

3.3.5  Description 

The  check  Flow  Restriction  object  examines  the  current/future  position  aircraft  data  generated  by  3.3. 1 
Time/Position  Calculation.  This  examination  looks  at  the  following: 

•  Sequencing  along  established  routes:  Flight  must  fly  along  a  given  route  with  certain  separation  stand¬ 
ards  intrail. 

•  Enroute  metering:  established  navigation  fixes  have  established  number  of  flight  that  can  cross  within  a 
given  timeframe. 

•  Flow  restrictions:  includes  broken  navigation  aids  or  closed  airports  that  are  to  be  avoided. 

If  any  violations  are  detected,  conflict  situation  data , s  passed  to  3.3.3  Alert  Processing. 

3.3.5  Inputs 

•  PREDICTED_TRACK_DATA  -  Predicted  track  data  is  predicted  positions  of  known  aircraft  tracks 
based  on  previous  track  history. 

3.3.5  Outputs 

•  CONFLICT_SITUATION_DATA  -  Data  concerning  a  particular  conflict  which  has  been  identified. 
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3.4  Strategic  Resolution  Discussion 

The  3.4  Strategic  Resolution  object  receives  resolution  requests  from  3.0  Prediction  and  Resolution,  which  it 
passes  to  it's  children  for  resolution  processing:  Flow  Control  Delay  processing,  Conflict  Resolution  proc¬ 
essing,  or  Flight  Plan  Reconformance  processing.  The  children  of  3.4  Strategic  Resolution  are  shown  in 
Figure  34  on  page  93. 
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Figure  34.  3.4  Strategir  Resolution  DFD.  This  figure  is  the  data  (low  diagram  for  the  IOM  Object,  3.4  Strategic 
Resolution. 
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3.4.1  Flow  Control  Delays 

3.4.1  Description 

The  Flow  Control  Delays  object  generates  aircraft  delay  requests  in  order  to  avoid  overcrowding  a  particular 
piece  of  airspace.  This  results  in  a  trial  flight  plan  which  is  sent  via  3.4  to  3.3  Strategic  Predn'tion  for  evalu¬ 
ation.  This  object  is  invoked  by  8.0  Area  Control  request  for  flow  control  delay  processing. 

3.4.1  Inputs 

•  DELAY_REQUEST  -  Request  from  controller  to  delay  an  aircraft's  progress  in  order  to  avoid  over¬ 
crowding  at  specific  places. 

•  WEATHER_SURV_INFO  -  Weather  information  in  the  form  of  radar  data  and  reports  on  pressure, 
winds  aloft,  temperature,  etc. 

3.4.1  Outputs 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 

3.4.2  Conflict  Resolution 

3.4.2  Description 

The  Conflict  Resolution  object  responds  to  a  request  by  the  controller  for  aid  in  resolving  an  identified  con¬ 
flict.  Trial  flight  plans  arc  generated,  in  the  form  of  calculated  resolutions,  which  are  sent  through  3.4  to  3.3 
Strategic  Prediction  for  evaluation. 

3.4.2  Inputs 

•  RESOLUTION_REQUEST  -  Request  from  the  controller  for  aid,  in  the  form  of  potential  solution,  in 
resolving  an  identified  conflict. 

•  WEATHER_SURV_INFO  -  Weather  information  in  the  form  of  radar  data  and  reports  on  pressure, 
winds  aloft,  temperature,  etc. 

3.4.2  Outputs 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 

3.4.3  Flight  Plan  Reconformance 

3.4.3  Description 

The  Flight  Plan  Reconformance  object  is  invoked  upon  8.0  area  control  request  to  generate  a  trail  flight  plan 
which  would  bring  a  flight  which  strayed  from  its  flight  plan  back  on  course.  This  trial  flight  plan,  in  the 
form  of  a  calculated  resolution,  is  sent  via  3.4  to  3.3  Strategic  Prediction. 

3.4.3  Inputs 

•  RECONFORMANCE_REQUEST  -  Request  from  the  controller  for  aid  in  bringing  a  strayed  flight 
back  into  conformance  with  its  flight  plan. 

•  WEATHER_SURV_INFO  -  Weather  information  in  the  form  of  radar  data  and  reports  on  pressure, 
winds  aloft,  temperature,  etc. 
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3.4.3  Outputs 

•  CALCULATED_RESOLUTION  -  Resolutions  calculated  by  the  Strategic  Resolution  function,  in 
response  to  controller  request  for  resolution. 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  3.0  Prediction 
and  Resolution. 

''All  Data  Flows"  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  flows  for  the  Prediction  and 
Resolution  object. 


S 
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DATE:  2S-APR-90 
TIKE:  1S:52 


PAGE  1 
EXCEL/RTS 


m  ALL  DATA  FLOWS  FOR  »f* 
xa  PREDICTIOI!  AND  RESOLUTION 


Na*e  A1 ternais  Naie  Short  Descrip.  Last  Modify  Date 


HOI  18 

ALERT  CLASSIFICATION 

CLASSIFICATION  OF  THE  ALERT  AS  WARNING,  SERIOUS,  CRITICAL. 

900122 

H0I04 

ALERT  DATA 

DATA  DESCRIBING  A  CONFLICT  BETWEEN  AN  AIRCRAFT  AND  ANOTHER 
AIRCRAFT  OR  AN  AIRCRAFT  AND  THE  GROUND. 

900122 

HOI  17 

ALERT  DISPLAY  DATA 

DATA  SENT  BY  THE  TACTICAL  PREDICTION  FUNCTION  TO  THE 

CONTROLLER  TO  NOTIFY  OF  IDENTIFIED  CONFLICTS  OR  ALERTS. 

900122 

HO  130 

ANALYSIS  LOG 

DATA  LOGGED  BY  THE  3.0  PREDICTION  i  ANALYSIS  OBJECT  AND  ITS 
CHILDREN 

900122 

HO  109 

ANALYSIS  RESULTS  DISPLAY/RES  RED  RESULTS  OF  THE  PREDICTION  AND  RESOLUTION  OBJECT  AND 

RESOLUTION  REQUESTS  FROM  THE  CONTROLLER 

900122 

H0113 

CALCULATED  RESOUHON 

RESOLUTIONS  CALCULATED  BY  THE  STRATEGIC  RESOLUTION 

FUNCTION,  IN  RESPONSE  TO  CONTROLLER  REQUEST  FOR  RESOLUTION. 

900122 

HOI  S3 

COMPARE  RESULTS 

RESULTS  OF  COMPARING  A  FLIGHT'S  PATH  WITH  ITS  FLIGHT  PLAN 
TRAJECTORY 

900122 

HOI  12 

CONFLICT  SITUATION 

POTENTIAL  CONFLICTS  UNCOVERED  IN  THE  ANALYSIS  OF  FLIGHT 

PLAN  DATA,  INCLUDING  FUTURE  AIRCRAFT-TO-AIRCRAF!  CONFLICTS. 

39121S 

H0105 

CONFLICT  SITUATION  DATA 

DATA  CONCERNING  A  PARTICULAR  CONFLICT  WHICH  HAS  BEEN 

IDENTIFIED 

9vQ!19 

HO  103 

CORRELATED  TRACK  DATA 

TPACK  DATA  THAT  HAS  BEEN  CORRELATED  rfITH  AN  APPROPRIATE 

FLIGHT  PLAN 

900122 

HOI  14 

DELAY  REQUEST 

REQUEST  FROM  CONTROLLER  TO  DELAY  AN  AIRCRAFT'S  'RCSRESS 

IN  ORDER  TO  AVOID  0VERCR0MDIN6  AT  SPECIFIC  PLACES. 

90011c 

HO!  19 

EVASIVE  MANEUVERS 

MANEUVERS  GENERATED  TC  AVOID  IMMINENT  CONFLICT.  COMPOSED 

OF  TURNS,  ACCElERAT I ON/DECELERATIONS .  ALTITUDE  CHANGES. 

9C>V  1 22 

HO  102 

FLIGHT  PLAN  CHANGES 

A  flight  plan  xnose  status  has  caanqed,  it  aay  nave  oeen 
initiated,  aaendec,  or  initali:ed  (fliqr.i  departed. 

59151c 

Milll 

PLIGHT  PLAN  CHANGES/CONFLICT  SIT  CHANGES  IN  FLIGHT  PLANS  DUE  ’0  STATE  CHANGES.  CONFLICT 

SITUATIONS  RESULTING  FROM  STRATEGIC  PREDICTION. 

500122 

>10122 

FLIGHT  PLAN  DATA*b„0CK  INFO 

FLIGHT  PLAN  INFORMATION  TO  BE  INCLUDED  ON  TriE  SURVEILLANCE 

DISPLAY  THAT  CORRESPONDS  TO  SPECIFIC  FLIGHT  PLANS. 

jijoisa 

rOiil 

'LIGHT  PLAN  EVENT 

AN  EVENT  FOR  A  FLIGHT  PLAN,  SUCH  AS  WEN  IT  CRESSES  A 

METERING  FIT 

900122 

-iO .  £4 

plight  plan  pesnoN 

COORDINATE  POSITIONS  OF  AN  AIRCRAFT  ON  A  'LIGHT  PLAN 

900122 

•I’.'lEi 

CF  EVENT  '  STATUS 

FLIGHT  PLAN  EVENT,  3LCH  AS  FIX  CROSSINGS,  AND  BTA’uS.  SUCH 

AS  NONCONFORMANCE  REPORTS. 

50*j1c2 

DATE: 

TIME: 

26-APR-90 

18:52 

m  ALL  DATA  FLOWS  FGR  *** 

«*  PREDICTION  AND  RESOLUTION 

PAGE  2 

EXCEL/STS 

Naae 

Alternate  Nane 

Short  Descrip. 

Last  Modify  Date 

KOI  20 

NON-CONFORMANCE  ALERT 

ALERT  TO  TO  BE  RECORDED  FOR  FAILURE  OF  A  FLIGHT  TO  STAY  ON 
ITS  FLIGHT  PLAN 

900122 

H0127 

NONCONFORMANCE  ALERTS 

ALERTS  SENT  TO  RECORDING  SUPPORT  WHEN  A  FLIGHT  IS  OUT  OF 
CONFORMANCE  WITH  ITS  FLIGHT  PLAN 

S91218 

H0104 

PREDICTED  TRACK  DATA 

PREDICTED  TRACK  DATA  IS  PREDICTED  POSITIONS  OF  KNOWN 

AIRCRAFT  TRACKS  BASED  ON  PREVIOUS  TRACK  HISTORY. 

900122 

-.0115 

RECONFGRMANCE  REQUEST 

REQUEST  FROM  THE  CONTROLLER  FGR  AID  IN  BRINGING  A  STRAYED 
FLIGHT  SACK  INTO  CONFORMANCE  WITH  ITS  FLIGHT  PLAN. 

9001 19 

HO!  14 

RESOLUTION  REQUEST 

REQUEST  FROM  THE  CONTROLLER  FOR  AID,  IN  THE  FORM  OF 

POTENTIAL  SOLUTIONS,  IN  RESOLVING  AN  IDENTIFIED  CONFLICT. 

900119 

10108 

RESOLUTION  REQUESTS 

Requests  fro»  the  controller  for  resolutions  to  near-tera, 
but  not  isaediate,  probleas  (e.q.  fliqht'plan  non  confer#). 

891218 

M1S4 

TRACK  CLASSIFICATION 

A  CLASSIFICATION  OF  AN  IDENTIFIED  TRACK,  SUCH  AS  FREE  (NO 
FLIGHT  PLAN  ASSOC),  FLIGHT  PLAN  AIDED,  OR  COAST. 

900122 

H0128 

TFACK  DISPLAY  DATA 

DISPLAY  DATA  CONTAINING  FLIGHT  DATA  BLOCKS  AND  TRACK 
CLASSIFICATIONS. 

891215 

HC125 

TRACK  DISPLAY  DATA 

DATA  ABOUT  THE  IDENTIFIED  TRACKS  TO  BE  PRESENTED  TO  THE 
CONTROLLER,  INCLUDING  CORRELATED  FLIGHT  PLANS  AND  CLASSIFCTN 

900122 

tiOlOi 

"RAFFIC  SURVEILLANCE  DATA 

Traffic  Surveillance  Data  is  radar  generated  data  showing 
the  air  traffic,  includes  oosition,  beacon  cods,  altitude. 

9C01I1 

HOi  10 

HEATHER  3USV  INFO 

HEATHER  INFORMATION  IN  THE  FORM  OF  RADAR  DATA  AND  REPORTS 

ON  PRESSURE,  HINDS  ALOFT,  TEMPERATURE,  ETC. 

S91218 
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'All  Records  and  their  Elements'  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  the  records  and  their  elements 
for  the  Prediction  and  Resolution  object. 
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DATE:  E5-APR-90 
TIKE:  15:41 

Na«e 

ALERT  DATA 

ALERT  DISPLAY  DATA 

ANALYSIS  LQC- 

ANALYSIS  RESULTS  DISPLAY 

ANALYSIS  RES  i  RESOLUTION  RE3 

CALCULATED  RESOLUTION 

COMPARE  RESULTS 

CONFLICT  SITUATIONS 
CONFLICT  SITUATION  DA"A 

CORF  ELATED  TRACK  DATA 

■ELAY  REQUEST 

■  hSI'.E  MANEUVERS 

FLIGHT  PLAN  DATA  BLOCK  i.tf-3 


***  AlL  RECORDS  FOR  *«  PAGE  1 

««  PREDICTION  AND  RESOLUTION  it*  EXCEL/RT! 


=1  ELE/REC  Naae 


)+  Definition 


=  ALERT  ID 
+  ALERT  TYPE 

*  AIRCRAFT  ID 

+  PREDICTED  TRACK  POSITION 
t  O'HER  AIRCRAFT  ID 
i  TIKE  3EF0FE  IMPACT 

=  ALERT  ID 
+  FLIGHT  PLAN  ID 

♦  AIRCAFT  POSITION  DATA 
t  ALERT  TYPE 

*  ALERT  INFORMATION 

=  ALERT  DATA 

♦  CONFLICT  SITUATION  DATA 

=  ALERT  DISPLAY  DATA 

♦  EVASIVE  MANEUVERS 

=  ANALYSIS  RESULTS  DISPLAY 
i  RESOLUTION  REQUEST 

=  FLIGHT  PLAN  ID 

*  PROPOSED  FLIGHT  PLAN  UPDATE 

=  FLIGHT  PLAN  ID 
+  TRACK  COAST 
r  FREE  TRACK 


=  FLIGHT  PLAN  ID 
+  CONFLICT  TYPE 
f  INVOLVED  AIRCRAFT 
f  TIME  3EFGRE  INCIDENT 

=  TRACK  ID 

-(  FLIGHT  PLAN  ID  ) 

t  FLISHT  POSITION 

=  -LISf-T  P-AN  ID 

-  LENGTH  Dr  DELAY 

t  METERING  FIX 

=  alert  id 

i  MANEUVER 
=  TRACK  19 

(•  FLIGHT  ftAN  ID  ! 

f  SUMMARISED  TRACI  INFO 


DATE:  So-APR-'O  ***  ALL  RECORDS  FOR  «*  PAGE  2 

TIME:  16:41  ***  PREDICTION  AND  RESOLUTION  «*  EXCEL/P.TS 


Na»e 


=(  ELE/REC  Naie 


)+  Definition 


FLIGHT  PLAN  EVENT 


=  FLIGHT  PLAN  ID 
+(  NETER  FIX  CROSSING 
H  HANDQFF 

+(  INITIATE  TRACKING 
+(  TERMINATE  FLIGHT 

=  FLIGHT  POSITION 

=  NONCONFORMANCE  ALERT 

=  LATITUDE 
+  LONGITUDE 
+(  ALTITUCE 
*(  VELOCITY 


FP  CHANGES  L  CONFLICT  SITUATIONS  =  FLIGHT  PLAN  CHANGES 

+  CONFLICT  SITUATION  DATA 


FLIGHT  PLAN  POSITION 
CLIGHT  PLAN  STATUS 
FLIGHT  POSITION 


FP  EVENT  /  STATUS 


MANEUVER 


NONCONFORMANCE  ALERT 

POSITION  DATA 
PREDICTED  TRACK  DATA 
RSCONFDRKANCE  PECl’EST 

RESOLUTION  REQUEST 

SUMMARISED  FLicriT  PLAN  DATA 


=  FLIGHT  PLAN  EVENT 
+  FLIGHT  PLAN  STATUS 

=  COMMAND 

*  DIRECTION 
+  DURATION 

*  SPEED 

+  QUALIFIER 

=  FLIGHT  PLAN  ID 
r  -LIGHT  POSITION 


=  TRACK  DATA  INSTANCE 

=  FLIGHT  PLAN  ID 
+  CURRENT  POSITION 

=  FLIGHT  PLAN  ID 
+  CURRENT  POSITION 
*  CONFLICT  TVPE 

=  FLIGFT  ID 
=(  AIRCRAFT  TYPE 
=  AIRSPEED 
=i  DESTINATION 
=  FLIGHT  POSITION 
=f  BEACON  CODE 


SUMMARISED  FLIGHT  5LAI<  INFO 
SUMMARISED  TRACK  LATA 


■DATE:  2&-APR-90 

»**  ALL  RECORDS  FOR  *« 

PAGE  3 

TIME:  18:41 

*«  PREDICTION  AND  RESOLUTION 

EXCEL/RTS 

Nane 

=(  ELE/REC  Naae 

)+  Definition 

SUMMARISED  TRACK  INFO 

=1  AIRCRAFT  ID 

H  AIRCRAFT  TYPE 
+  VELOCITY 
+  FLIGHT  POSITION 
+(  DESTINATION 

) 

1 

! 

TRACK  CLASSIFICATION 

TRACK  DATA  INSTANCE 

=  TIKE  STAMP 
r  AIRCRAFT  POSITION  DATA 

TRACK  DISPLAY  DPTA 

=  TRACK  ID 
+(  FLIGHT  PLAN  IS 

*  TRACK  CLASSIFICATION 

♦  SUMMARISED  TRACK  INFO 

) 
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"All  DaH  Stores"  Report 

3.0  Prediction  and  Resolution  employs  the  following  globally  defined  data  stores  defined  in  Appendix  A  of 
this  document: 

•  AIRCRAFT j\ND_ENVIRONMENT_DATA 

•  TRACK.HISTORY 

•  FLIGHT_PLANS 

•  AIRPORT_AND_AP_STATUS. 
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5.0  Aircraft  and  Track  Management 

Introduction 

5.0  Aircraft  and  Track  Management  is  responsible  for  correlating  identified  aircraft  tracks  to  flight  plan  data 
and  for  identifying  when  aircraft  cross  metering  fixes. 

The  AIRCRAFT  AND  TRACK  MANAGEMENT  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Aircraft  and  Track  Management  View  From 

•  The  Aircraft  and  Track  Management  Interfaces 

•  The  Aircraft  and  Track  Management  Functional  Object  Tree 

•  Aircraft  and  Track  Management. 

5.0  Aircraft  and  Track  Management  "View  From" 

The  relationship  on  5.0  Aircraft  and  Track  Management  to  other  Major  Functional  Objects  is  shown  in 
Figure  35  on  page  100.  It  is  activated  by  Traffic  Surveillance  Data  received  from  1.0  Traffic  Surveillance. 
Using  data  stores  Flight  Plans  and  Aircraft  and  Environment  Data,  5.0  generates  Non-conformance  Alerts  to 
4.0  Recording  Support  and  Track  Display  Data  to  8.0  Area  Control.  It  also  updates  the  Meterable  Fix 
Counts  data  store  and  sends  Flight  Plan  Events  and  Status  to  6.0  Flight  Plan  Entry  Support. 
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Figure  35.  DoD  AAS  View  From  Aircraft  and  Track  Management.  This  figure  highlights  the  Aircraft  and  Track 

Management  functional  object  and  shows  the  flow  of  information  to  and  from  the  other  functional  objects 
in  the  DoD  AAS  ATC  Model. 
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5.0  Aircraft  and  Track  Management  Interfaces 

The  interfaces  to  5.0  Aircraft  and  Track  Management  are  shown  in  Figure  36  on  page  102.  It  passes  Traffic 
Surveillance  Data  to  5.1  Correlate  Track  and  Flight  Plan. 
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5.0  AIRCRAFT  &  TRACK  MANAGEMENT  INTERFACES 

1.0  TRAFFIC  SURVEILLANCE 


5.1  CORRELATE  TRACK  AND  FLIGHT  PLAN 


Figure  36.  Aircraft  and  Track  Management  Interfaces.  This  figure  shows  the  interfaces  with  the  Aircraft  and  Track 
‘  Management  functional  object,  and  the  other  functional  objects  of  the  DoD  AAS  ATC  Model. 

5.0  Inputs 
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•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

5.0  Outputs 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

5.0  Aircraft  and  Track  Management  Functional  Object  Tree 

The  functional  object  tree  identifies  the  communication  paths  between  the  functional  objects  in  the  Aircraft 
and  Track  Management  process.  Figure  37  on  page  104  shows  the  Functional  Object  Tree. 
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5.0  CONTROL  FUNCTIONAL  OBJECT  TREE 


F.gure  37.  3.0  Aircraft  and  Track  Management  Functional  Object  Tree.  This  figure  illustrates  the  functional  object 
tree  for  the  Aircraft  and  Track  Management  Functional  Object. 
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5.0  Aircraft  and  Track  Management  Discussion 

The  Aircraft  &  Track  Management  object,  shown  in  Figure  38  on  page  106,  passes  flight  surveillance  data 
from  1.0  traffic  surveillance.  This  data  is  used  to  correlate  flight  plans  to  tracks  and  to  check  to  see  if  a  track 
has  strayed  from  its  flight  plan. 
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Figure  38.  5.0  Aircraft  and  Track  Management.  This  figure  is  the  IOM  object  decomposition  of  the  Aircraft  and 
Track  Management  Functional  Object. 
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5.1  Correlate  Track  and  Flight  Plan 

5.1  Description 

The  Correlate  Track  and  Flight  Plan  object  receives  aircraft  surveillance  data  originating  in  1.0  Traffic  Sur¬ 
veillance.  The  surveillance  data  is  composed  of  multiple  aircraft  tracks,  composed  of  position,  altitude,  and 
(possibly)  beacon  code.  If  the  beacon  code  exists,  the  flight  plan  data  base  is  searched  for  a  flight  plan 
whose  assigned  beacoa  code  matches  it.  Flight  plan  correlation  of  all  tracks  is  attempted. 

5.1  Inputs 

•  TRAFFIC_SURVEILLANCE_DATA  -  Traffic  Surveillance  Data  is  radar  generated  data  showing  the 
air  traffic,  includes  position,  beacon  code,  altitude. 

5.1  Outputs 

•  CORRELATED_TRACK_DATA  -  Track  data  that  has  been  correlated  with  an  appropriate  flight  plan. 

5.2  Flight  Plan  Conformance  Check 

5.2  Description 

The  Flight  Plan  Conformance  Check  object  passes  through  the  necessary  correlated  track  data. 

5.2  Inputs 

•  CORRELATED_TRACK_DATA  -  Track  data  that  has  been  correlated  with  an  appropriate  flight  plan. 
5.2  Outputs 

•  CORRELATED_TRACK_DATA  -  Track  data  that,  has  been  correlated  with  an  appropriate  flight  plan. 
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5.2  Flight  Plan  Conformance  Check  Discussion 

The  5.2  Flight  Plan  Conformance  compares  flight  plan-aided  aircraft  progress  to  flight  plan  data  and  notes 
anomalies.  The  children  of  5.2  Flight  Plan  Conformance  Check  are  shown  in  Figure  39  on  page  109. 
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Figure  39.  5.2  Flight  Plan  Conformance  Check.  This  figure  is  the  data  flow  diagram  for  the  IOM  Object,  5.2  Flight 
Plan  Conformance  Check 
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5.2.1  Compare  Flight  Plan  to  Track  Data 

5.2.1  Description 

The  Compare  Flight  Plan  to  Track  Data  object  examines  each  track  with  a  correlated  flight  plan.  For  each 
identified  flight  plan,  a  window  is  drawn  around  the  expected  flight  plan  position  and  if  the  measured  track  is 
not  within  the  window,  a  nonconformance  report  is  issued.  The  results  are  passed  to  5.1.3  Generate  Track 
Classification  and  the  corresponding  data  blocks  are  passed  to  5.1.4  Coalesce  Flight  Plan. 

5.2.1  Inputs 

•  CORRELATED_TRACK_DATA  -  Track  data  that  has  been  correlated  with  an  appropriate  flight  plan. 

5.2.1  Outputs 

•  FLIGHT_PLAN_DATA-BLOCK_INFO  -  Flight  plan  information  to  be  included  on  the  surveillance 
display  that  corresponds  to  specific  flight  plans. 

•  FLIGHT_PLANJEVENT  -  An  event  for  a  flight  plan,  such  as  when  it  crosses  a  metering  fix. 

•  FLIGHT_PLAN_POSmON  -  Coordinate  positions  of  an  aircraft  on  a  flight  plan. 

•  COMPARE_RESULTS  -  Results  of  comparing  a  flight's  path  with  its  flight  plan  trajectory. 

•  NON-CONFORMANCE_ALERT  -  Alert  to  be  recorded  for  failure  of  a  flight  to  stay  on  its  flight  plan. 

5.2.2  Check  Metering  Fix  Crossing 

5.2.2  Description 

The  Check  Metering  Fix  Crossing  object  compares  the  position  of  the  correlated  track  to  known  metering 
fixes  and  updates  the  Meterable  Fix  Counts  data  store  if  a  fix  is  crossed. 

5.2.2  Inputs 

•  FLIGHT_PLAN_POSITION  -  Coordinate  positions  of  an  aircraft  on  a  flight  plan. 

5.2.2  Outputs 

None. 


5.2.3  Generate  Track  Classification 

5.2.3  Description 

The  Generate  Track  Classification  object  examines  the  comparison  results  and  classifies  each  track.  This 
classification  is  passed  on  to  the  8.0  Area  Controller. 

5.2.3  Inputs 

•  COMPARE_RESULTS  -  Results  of  comparing  a  flight's  path  with  its  flight  plan  trajectory. 

5.2.3  Outputs 

•  TRACK_CLASSIFICATION  -  A  Classification  of  an  identified  track,  such  as  free  (no  flight  plan  asso¬ 
ciation),  flight  plan  aided,  or  coast. 

5.2.4  Coalesce  Flight  Plan  and  Track  Information 
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5.2.4  Description 

The  Coalesce  Flight  Plan  and  Track  Information  object  collects  the  flight  plan  data  block  information  for  a 
particular  track  and  coalesces  it  with  the  track  classification  for  output  to  8.0  Area  Controller. 


5.2.4  Inputs 

•  FLIGHT_PLAN_DATA-BLOCK_INFO  -  Flight  plan  information  to  be  included  on  the  surveillance 
display  that  corresponds  to  specific  flight  plans. 

•  TRACK_CLASSIFICATION  -  A  Classification  of  an  identified  track,  such  as  free  (no  flight  plan  asso¬ 
ciation),  flight  plan  aided,  or  coast. 

5.2.4  Outputs 

•  TRACK_DISPLAY_DATA  -  Data  about  the  identified  tracks  to  be  presented  to  the  controller, 
including  correlated  flight  plans  and  classification. 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  5.0  Aircraft 
and  Track  Management. 

"All  Data  Flows"  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  flows  for  the  Aircraft  and 
Track  Management  object. 
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DATE:  2S-APR-90 
TIME:  19:14 


hi  ALL  DATA  FLOWS  FOR  •  *« 

*«  AIRCRAFT  AND  TRACK  MANAGEMENT  h* 


PAGE  1 
EXCEL/RTS 


Naae 

Alternate  llase 

Short  Descrip. 

Last  Modify  Dace 

HOI  13 

ALERT  CL ASS I F 1 CAT I GN 

CLASSIFICATION  OF  THE  ALERT  AS  WARNING,  SERIOUS,  CRITICAL. 

9001 EE 

H0104 

ALERT  DATA 

DATA  DESCRIBING  A  CONFLICT  BETWEEN  AN  AIRCRAFT  AND  ANOTHER 
AIRCRAFT  OR  AN  AIRCRAFT  AND  THE  GROUND. 

900122 

H01S7 

ALERT  DISPLAY  DATA 

DATA  SENT  BY  THE  TACTICAL  PREDICTION  FUNCTION  TO  THE 
CONTROLLER  TO  NOTIFY  OF  IDENTIFIED  CONFLICTS  GR  ALERTS. 

900122 

H0130 

ANALYSIS  LOG 

DATA  LOGGED  BY  THE  3.0  PREDICTION  l  ANALYSIS  OBJECT  AND  ITS 
CHILDREN 

900 122 

HO  109 

ANALYSIS  RESULTS  DIS1AY/RES  REfi  RESULTS  OF  THE  PREDICTION  AND  RESOLUTION  OBJECT  AND 

RESOLUTION  REQUESTS  FROM  THE  CONTROLLER 

900122 

H0113 

CALCULATED  RESOLUTION 

RESOLUTIONS  CALCULATED  BY  THE  STRATEGIC  RESOLUTION 

FUNCTION,  IN  RESPONSE  TQ  CONTROLLER  REQUEST  FOR  RESOLUTION. 

900122 

H0123 

COMPARE  RESULTS 

RESULTS  OF  COMPARING  A  FLIGHT'S  PATH  WITH  ITS  FLIGHT  PLAN 
TRAJECTORY 

900122 

HOI  12 

CONFLICT  SITUATION 

POTENTIAL  CONFLICTS  UNCOVERED  IN  THE  ANALYSIS  OF  FLIGHT 

FLAN  DATA,  INCLUDING  FUTURE  AIRCRAFT-TG-AIRCRAFT  CONFLICTS. 

39121S 

u0105 

CONFLICT  SITUATION  DATA 

DATA  CONCERNING  A  PARTICULAR  CONFLICT  WHICH  HAS  BEEN 
IDENTIFIED 

900119 

‘•'OIOS 

CORRELATED  TRACK  DATA 

TRACK  DATA  THAT  HAS  BEEN  CORRELATED  UITH  AN  APPROPRIATE 
FLIGHT  FLAN 

=00122 

HO:  ^ 

DELAY  REQUEST 

REQUEST  FROM  CONTROLLER  TO  DELAY  AN  AIRCRAFT'S  PROGRESS 

IN  ORDER  TO  AVOID  OVERCROWDING  AT  SPECIFIC  PLACES. 

90011s 

“Oil? 

EVASIVE  MANEUVERS 

MANEUVERS  GENERATED  TO  AVOID  IMMINENT  CONFLICT,  COMPOSED 

OF  TURNS,  ACCElERATIGN/DECSLERATIGNS.  ALTITUDE  CHANGES. 

50)132 

K‘102 

FLIGHT  FLAN  Ch«NGE3 

A  flight  plan  whose  status  has  changed.  It  nay  have  been 
initiatea,  aae.ided,  or  mitalized  (flight  departed). 

391213 

J-  M  * 

PLIGHT  CHANGES/ CONFLICT  SIT 

CHANGES  IS  FLIGHT  PLANS  DUE  TO  STATE  CHANGES.  CONFLICT 
SITUATIONS  RESULTING  FROM  STRATEGIC  PREDICTION. 

900122 

hi  i po 

=LIGHT  ?.A!i  DAT-i-BLGCK  INFO 

FLIGHT  PLAN  INFORMATION  TO  EE  INCLUDED  GN  THE  SLSVEILtANCE 
DISPLAY  THAT  COF.RES°ONDS  TO  SPECIFIC  FLIGHT  PLANS. 

900122 

or  J2! 

FL53HJ  PLAN  EVENT 

AN  EVENT  FOR  A  FLIGHT  PLAN,  SUCH  AS  .iHEN  IT  CROSSES  A 
METERING  FIX 

90(152 

p.j:s5 

flight  plan  position 

COORDINATE  POSITIONS  0=  AH  AIRCRAF"  GN  A  FLIGHT  PLAN 

900122 

4012: 

FC  EVEN’  ■'  S'A'L'S 

FLIGHT  PLAN  EVENT.  3LG-i  AS  FIX  CROSSINGS,  AND  STATUS,  SuCH 

AS  SONCCN'QFMANGE  REPORTS. 

=00122 

DATE:  24-APR-=0 

TIME:  19:15 

m  ALL  DATA  FLOWS  FOR 

AIRCRAFT  AND  TRACK  MANAGEMENT  m 

PAGE  E 

EXCEL/RTS 

Nate  Alternate  Naee 

Short  Descrip. 

Last  Modify  Date 

HOI 20  NON-CONFORMANCE  ALERT 

ALERT  TO  TO  BE  RECORDED  FOR  FAILURE  OF  A  FLIGHT  TO  STAY  ON 
ITS  FLIGHT  PLAN 

900122 

HO 127  NONCONFORMANCE  ALERTS 

ALERTS  SENT  TO  RECORDING  SUPPORT  WHEN  A  FLIGHT  IS  OUT  OF 
CONFORMANCE  WITH  ITS  FLIGHT  PLAN 

891218 

HO 104  PREDICTED  TRACK  DATA 

PREDICTED  TRACK  DATA  IS  PREDICTED  POSITIONS  OF  KNOWN 

AIRCRAFT  TRACKS ’BASED  ON  PREVIOUS  TRACK  HISTORY. 

900122 

HOI  15  RECONFORMANCE  REQUEST 

REQUEST  FROM  THE  CONTROLLER  FOR  AID  IN  BRINGING  A  STRAYED 
FLIGHT  BACK  INTO  CONFORMANCE  WITH  ITS  FLIGHT  PLAN. 

900118 

HOI  14  RESOLUTION  REQUEST 

REQUEST  FROM  THE  CONTROLLER  FOR  AID,  IN  THE  FORM  OF 

POTENTIAL  SOLUTIONS,  IN  RESOLVING  AN  IDENTIFIED  CONFLICT. 

900119 

R0108  RESOLUTION  REQUESTS 

Requests  fro*  the  controller  for  resolutions  to  near-tera, 
but  not  iseediate,  profcleas  (e.q.  flight  plan  non  confora). 

391213 

HO 124  TRACK  CLASSIFICATION 

A  CLASSIFICATION  CF  AN  IDENTIFIED  TRACK,  SUCH  AS  FREE  (NO 
FLIGHT  PLAN  ASSOC),  FLIGHT  PLAN  AIDED,  OR  COAST. 

900122 

HOI 23  TRACK  DISPLAY  DATA 

DISPLAY  DATA  CONTAINING  FLIGHT  DATA  BLOCKS  AND  TRACK 
CLASSIFICATIONS. 

391218 

HO 125  TRACK  DISPLAY  DATA 

DATA  ABOUT  THE  IDENTIFIED  TRACKS  TO  BE  FRESENTED  TO  THE 
CONTROLLER,  INCLUDING  CORRELATED  FLIGHT  PLANS  AND  CLAS5IFCTN 

900122 

HOI 01  TRAFFIC  SURVEILLANCE  DATA 

Traffic  Surveillance  Data  :s  radar  generated  data  showing 
the  air  traffic,  includes  position,  beacon  code,  altitude. 

900111 

MHO  ’HEATHER  SURV  INFO 

WEATHER  INFORMATION  IN  THE  FORM  OF  RADAR  DATA  AND  REPORTS 

SN  PRESSURE,  WINDS  ALOFT,  TEMPERATURE,  ETC. 

89121S 
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'All  Records  and  their  Elements'  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  the  records  and  their  elements 
for  the  Aircraft  and  Track  Management  object. 
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PAGE  1 
EXCEL/RTS 


Naae  *(  ELE/REC  Nate  )+  Definition 

ALERT  DATA  =  ALERT  ID 

+  ALERT  TYFE 

♦  AIRCRAFT  ID 

+  PREDICTED  TRACK  POSITION 

♦  OTHER  AIRCRAFT  ID 
+  TIME  BEFORE  IMPACT 

ALERT  DISPLAY  DATA  =  ALERT  ID 

♦  :LI6HT  PLAN  ID 

+  AIRCAFT  POSITION  DATA 
+  ALERT  TYPE 
+  ALERT  INFORMATION 

ANALYSIS  uOS  =  ALERT  DATA 

+  CONFLICT  SITUATION  DATA 

ANALYSIS  RESULTS  DISPLAY  =  ALERT  DISPLAY  DATA 

+  EVASIVE  MANEUVERS 

ANAL VS IS  RES  i  RESOLUTION  REfl  =  ANALYSIS  RESULTS  DISPLAY 

♦  RESOLUTION  REQUEST 

CALCULATED  RESOLUTION  »  FlIGHT  PLAN  ID 

♦  PROPOSED  FLIGHT  PLAN  UPDATE 

COHERE  RESULTS  =  FLIGHT  PLAN  ID 

♦  TRACK  COAST 
t  FREE  TRACK 

CONFLICT  SITUATIONS 

CONFLICT  SITUATION  DATA  =  -LIGHT  FLAN  ID 

♦  CONFLICT  TYPE 

+  INVOLVED  AIRCRAFT 

♦  TIME  BEFORE  INCIDENT 

CORRELATED  TRACK  DATA  *  TRACK  ID 

*(  CLI5HT  PLAN  ID  ) 

♦  flight  position 


*  LENGTH  OF  DELAY 
+  METERING  FIX 

EVASIVE  MANELVER3  -  ALERT  ID 

+  MANEUVER 

'LIGHT  PL-ifi  DATA  BlCCK  I  NFC  =  TRACK  ID 

t<  FLIGHT  FLAN  ID 

*  SUMMARISED  TRACI  INFO 


DATE:  26-APR-90  «*  ALL  RECORDS  FOR  *« 

TIME:  19:16  ««  AIRCRAFT  1  TRACK  HANABHEKT  *** 


* 


DATES  24-APR-9Q 
USE:  19:16 


*f*  Alt  RECORDS  Fr  **» 

*h  AIRCRAFT  i  TRACK  MkhASMENT  *« 


=(  ELE/REC  Naif 


)t  Definition 


RASE  2 
EXCEL/RTS 


FLIGHT  PLAN  EVENT 


FLISHT  PLAN  POSITION 


•LIGHT  PLAN  STATUS 


FLIGHT  PGSITION 


rp  CHANGES  l  CONFLICT  SITUATIONS 


FP  EVENT  /  STATUS 


MANEUVER 


NONCONFORMANCE  ALERT 


POSITION  DATA 


FREE ICTED  TRACK  DATA 


RECGNFORMANCE  RESUES7 


RESOLUTION  REQUEST 


SUMMARISED  -_I2HT  PLAN  DATA 


=  FLIGHT  PLAN  ID 
H  METER  FIX  CROSSING 
H  HANDOFF 

+{  INITIATE  TRACKING 
+(  TERMINATE  FLIGHT 

=  FLIGHT  POSITION 

=  NONCONFORMANCE  ALERT 

=  LATITUDE 
+  LONGITUDE 
H  ALTITUDE 
tl  VELOCITY 

.  FLISHT  PLAN  CHANGES 
+  CONFLICT  SITUATION  DATA 

=  FLIGHT  PLAN  EVENT 
+  FLIGHT  PLAN  STATUS 

=  COMMAND 
+  DIRECTION 

♦  DURATION 

♦  SPEED 

+  QUALIFIER 

=  FLISHT  PLAN  ID 
t  FLIEHT  POSITION 


=  ’RACK  DATA  INSTANCE 

=  FLIGHT  FLAN  ID 
f  CURRENT  POSITION 

=  FLIGHT  PLAN  i[ 
t  CURRENT  POSITION 
*  CONFLICT  TYPE 

=  'LIGHT  ID 
=(  AIRCRAFT  TYPE 
=  AIRSPEED 
=<  DESTINATION 
=  FLIGHT  POSITION 
=<  BEACON  CODE 


SI-UPRISES  FLIGHT  PLAN  INFO 


SUMMARISED  'SAC;  DATA 


DATE:  26-APR-90 
TIME:  19:15 

Nais 

SUMMARISED  TRACK  INFO 

TRACK  CLASSIFICATION 
TRACK  DATA  INSTANCE 

TRACK  DI8FLAV  DATA 


m  ALL  RECORDS  FOR  *♦*  •  RAGE  3 

t«  AIRCRAFT  &  TRACK  r.ANAGMENT  »*  EXCEL/RTS 


--(  ELE/REC  Na«e 


)+  Dsf inition 


=(  AIRCRAFT  ID  ) 

+(  AIRCRAFT  TYPE  ) 

♦  VELOCITY 

♦  FLIGHT  POSITION 

H  DESTINATION  ) 


=  TINE  STAMP 

♦  AIRCRAFT  POSITION  DATA 

*  TRACK  ID 

+1  FLIGHT  PLAN  ID  ) 

♦  TRACK  CLASSIFICATION 

*  SUMMARISED  TRACK  INFO 
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'All  Data  Stores'  Report 

5.0  Aircraft  and  Track  Management  employs/derives  the  following  globally  defined  data  stores  described  in 
Appendix  A  of  this  document: 

•  AIRCRAFT_AND_ENVIRONMENT_DATA  (employs) 

•  FLIGHT_PLANS  (employs) 

•  METERAB LE_F IX_COUNTS  (derives). 


5.0  Aircraft  and  Track  Management  113 


STARS  Deliverable  1200 


6.0  Flight  Plan  Entry  Support 

Introduction 

Flight  Plan  Entry  Support  is  the  single  entry  point  in  the  system  for  all  flight  plans.  Types  of  flight  plans 
which  may  be  entered  into  the  system  are  new  and  bulk  flight  plans;  flight  plan  amendments;  up-route  flight 
plans  (for  probe  extension);  flight  plans  received  during  handoff;  and  trial  flight  plans. 

The  FLIGHT  PLAN  ENTRY  SUPPORT  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Flight  Plan  Entry  Support  View  From 

•  The  Flight  Plan  Entry  Support  Interfaces 

•  The  Flight  Plan  Entry  Support  Functional  Object  Tree 

•  Flight  Plan  Entry  Support. 

6.0  Flight  Plan  Entry  Support  "View  From" 

Flight  Plan  Entry  Support  receives  new  flight  plans,  amendments,  updates,  trial  flight  plans,  and  handoffs 
from  Area  Control.  Updates  to  the  flight  plans  are  received  from  Aircraft  &  Track  Management.  Data  is 
stored  in  the  appropriate  flight  plan  database,  and  passed  to  Flight  Plan  Operations  Support  for  further  proc¬ 
essing.  Figure  40  on  page  1 16  presents  DOD  AAS  from  the  view  of  the  Flight  Plan  Entry  Support  process. 
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6.0  Flight  Plan  Entry  Support  Interfaces 

Figure  41  on  page  118  shows  the  data  flows  used  and  generated  by  Flight  Plan  Entry  Support.  New  flight 
plans,  amendments,  updates,  trial  flight  plans,  and  handoffs  are  received  from  Area  Control  (within  this 
center),  as  well  as  from  neighboring  Area  Control  Facilities,  Tower  Control  Facilities,  and  the  Flight  Service 
Data  Center  within  this  center.  Probe  extension  requests  may  also  come  from  a  neighboring  Area  Control 
Facility.  Updates  to  the  flight  plans  are  received  from  Aircraft  &  Track  Management. 

Flight  Plan  Entry  Support  receives  all  the  data  mentioned  above,  and  passes  it  to  the  appropriate  function  to 
be  processed.  The  new  flight  plans  and  flight  plan  amendments  are  sent  to  Initial  Flight  Plan  Processing. 
Initial  Flight  Plan  Processing  returns  errors  found  during  the  processing  of  the  flight  plan  data.  Probe  exten¬ 
sion  requests  and  trial  flight  plans  are  sent  to  Up-Route/Trial  Flight  Plan  Processing.  Flight  plan  updates 
are  sent  to  Flight  Plan  Update  Processing,  and  handoffs  into  the  area  are  sent  to  Handoff-In  Processing. 

Once  the  flight  plan  data  has  been  processed  by  Flight  Plan  Entry  Support,  it  is  passed  to  Flight  Plan  Oper¬ 
ation  Support. 
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6.0  FLIGHT  PLAN  ENTRY  SUPPORT  INTERFACES 


6.1  INITIAL  FLIGHT  PLAN 
PROCESSING 


6.2  UP-ROUTE/ 
TRIAL  FP 
PROCESSING 


6.3  FP 

UPDATE 

PROCESSING 


6.4 

HANDOFF-IN 

PROCESSING 


Figure  41.  Flight  Plan  Entry  Support  Interfaces.  This  figure  shows  the  interfaces  with  the  Flight  Plan  Entry  Support 
functional  object,  and  the  other  functional  objects  of  the  DoD  AAS  ATC  Model. 
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6.0  Inputs 

•  FPS_AMEND_UPDT_TRIAL_ERRORS  -  FP  data  sent  to  FLIGHT  PLAN  ENTRY  SUPPORT. 
Includes  new  FPs,  amendments,  updates,  trial  FPs,  and  handoffs. 

•  FP  EVENT  STATUS  -  Updates  to  time  fields  in  a  flight  plan.  Sent  from  AIRCRAFT  TRACK 
MANAGEMENT  to  FLIGHT  PLAN  ENTRY  SUPPORT. 

•  PROBE_EXTENSION_REQUEST  -  Request  for  a  probe  extension  for  a  specific  flight  plan.  Received 
from  an  up-route  center. 

•  HANDOFF-IN_DATA  -  Flight  Plan  from  which  handoff-in  processing  is  required.  Received  from  an 
up-route  center  and  sent  to  HANDOFF-IN  PROC. 

•  INITIAL_FP_PROC_ERRORS  -  Errors  sent  from  INITIAL  FP  PROC  to  FP  ENTRY  SUPPORT 
which  were  detected  during  syntax  or  geography  checking. 

6.0  Outputs 

•  FPS_AMEND_UPDT_TRIAL_ERRORS  -  Errors  sent  to  flight  plan  originator,  in  response  to  the  FP 
data  sent  to  FLIGHT  PLAN  ENTRY  SUPPORT.  Includes  new  FPs,  amendments,  updates,  trial  FPs, 
and  handoffs. 

•  NEW_FL1GHT_PLAN_MESSAGE  -  New  Flight  Plan  Message  sent  from  FP  ENTRY  SUPPORT  to 
INITIAL  FP  PROC.  to  be  syntax/geography  checked  and  stored. 

•  FLIGHT_PLAN_AMENDMENT  -  FP  amendment  sent  from  FP  ENTRY  SUPPORT  to  INITIAL 
FP  PROC.  to  be  syntax/geography  checked  and  stored. 

•  UP-ROUTE  PROBE  EXTEN  FP  -  Flight  Plan  sent  from  FP  ENTRY  SUPPORT  to 
UP-ROUTE/TRIAL  FP  PROC  to  be  stored  and  sent  to  FP  OPERATION  SUPPORT. 

•  UN-ROUTE  PROC.TRIAL  FP  -  Trial  FP  sent  from  FP  ENTRY  SUPPORT  to 
UP-ROUTE/TRLAL  FP  PROC  to  be  stored  and  sent  to  FP  OPERATION  SUPPORT  for  route  proc¬ 
essing. 

•  NEW  FP  UPDATES  -  Flight  Plan  Updates  sent  from  FP  ENTRY  SUPPORT  to  FP  UPDATE 
PROC  to  be  stored  and  sent  to  FP  OPERATION  SUPPORT. 

•  VALIDATED_FLIGHT_PLANS  -  FPs  sent  from  FP  ENTRY  SUPPORT  to  FP  OPERATION 
SUPPORT.  FPs  have  been  syntax  and  geographically  checked.  Need  route  processing. 
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6.0  Flight  Plan  Entry  Support  Functional  Object  Tree 

The  functional  object  tree  identifies  the  communication  paths  between  the  functional  objects  in  the  Flight 
Plan  Entry  Support  process.  Figure  42  on  page  121  shows  the  Functional  Object  Tree. 
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Figure  42.  6.0  Flight  Plan  Entry  Support  Functional  Object  Tree.  This  figure  illustrates  the  functional  object  iree  for 
the  Flight  Plan  Entry  Support  Functional  Object. 
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6.0  Flight  Plan  Entry  Support  Discussion 

Flight  Plan  Entry  Support  will  receive  the  flight  plan  message.  If  the  input  is  a  new  or  bulk  flight  plan,  or  if 
it  is  an  amendment  to  a  flight  plan,  Initial  Flight  Plan  Processing  is  performed  to  verify  the  syntax  of  the 
message  and  to  check  the  geographical  data  in  the  flight  plan.  Errors  from  this  processing  are  passed  back  to 
Flight  Plan  Entry  Support  to  be  sent  to  the  originator  of  the  flight  plan  message.  If  the  message  is  validated, 
Flight  Plan  Entry  Support  sends  the  flight  plan  to  Flight  Plan  Operations  Support  for  route  validation  and 
further  processing. 

If  the  input  is  an  extended  probe  request  from  an  up-route  center,  or  a  trial  flight  plan,  Up- Route/Trial 
Flight  Plan  Processing  is  performed  to  store  the  flight  plan  in  the  appropriate  database.  The  flight  plan  is 
then  sent  to  Flight  Plan  Operation  Support  by  Flight  Plan  Entry  Support. 

If  the  input  is  an  update  to  a  time  in  the  flight  plan,  Flight  Plan  Update  Processing  is  performed.  The  flight 
plan,  with  the  updated  times  are  then  sent  to  Flight  Plan  Operation  Support  by  Flight  Plan  Entry  Support. 

If  the  input  is  a  handoff  from  an  up-route  center,  Handoff-In  Processing  is  performed  to  notify  the  controller 
of  the  handoff,  and  put  the  flight  plan  into  the  system.  Figure  43  on  page  123  presents  the  processing  con¬ 
trolled  by  Flight  Plan  Entry  Support. 
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Figure  43.  6.0  Flight  Plan  Entry  Support.  This  figure  is  the  IOM  object  decomposition  of  the  Flight  Plan  Entry 
Support  Functional  Object. 
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6.1  Initial  Flight  Plan  Processing 

6.1  Description 

Initial  flight  Plan  Processing  processes  new  and  bulk  flight  plans,  as  well  as  flight  plan  amendments.  If  the 
input  is  a  flight  plan  amendment,  a  'new'  flight  plan  is  built. 

Syntax  Checker  and  Geography  Checker  are  called  to  verify  the  syntax  and  geography  data  in  the  flight  plan. 
If  errors  are  detected,  they  are  returned  to  Initial  Flight  Plan  Processing,  which  sends  the  error  message  to 
Flight  Plan  Entry  Support.  If  the  flight  plan  is  a  bulk  flight  plan,  after  the  message  has  been  successfully 
checked,  the  flight  plan  is  sent  to  Bulk  Flight  Plan  Processing  for  further  processing.  The  flight  plan  or 
amendment  is  stored  in  the  appropriate  database. 

6.1  Inputs 

•  NEW_FLIGHT_PLAN_MESSAGE  -  New  Flight  Plan  Message  sent  from  FP  ENTRY  SUPPORT  to 
INITIAL  FP  PROC.  to  be  syntax/geography  checked  and  stored. 

•  FLIGHT_PLAN_AMENDMENT  -  FP  amendment  sent  from  FP  ENTRY  SUPPORT  to  INITIAL 
FP  PROC.  to  be  syntax/geography  checked  and  stored. 

•  SYNTAX  ERROR  •  Error  found  by  SYNTAX  CHECKER  and  sent  to  INITIAL  FLIGHT  PLAN 
PROC. 

•  GEOGRAPHY  ERROR  -  Error  detected  by  GEOGRAPHY  CHECKER  and  sent  to  INITIAL  FP 
PROC. 

•  SYNTAX  GEOGRAPHY  VALIDATED  FP  -  Flight  Plan  which  has  been  syntax  and  geographically 
checked.  Sent  from  GEOGRAPHY  CHECKER  to  INITIAL  FP  PROC. 

6.1  Outputs 

•  INITIAL_FP_PROC_ERRORS  -  Errors  sent  from  INITIAL  FP  PROC  to  FP  ENTRY  SUPPORT 
which  were  detected  during  syntax  or  geography  checking. 

•  UN-VALIDATED  FLIGHT  PLAN  -  Flight  Plan  which  has  not  been  syntax  or  geographically 
checked.  Sent  from"  INITIALFP  PROC  to  SYNTAX  Checker. 

•  NEW_BULK_FLIGHTJPLAN  -  New  bulk  flight  plan,  sent  from  INITIAL  FP  PROC  to  BULK  FP 
PROC  to  be  stored  in  the  bulk  flight  plan  database. 

6.2  Up-Route  I  Trial  Flight  Plan  Processing 
Description 

Up*Route  /  Trial  Flight  Plan  Processing  receives  up-route  and  trial  flight  plans  from  Flight  Plan  Entry 
Support.  This  process  updates  the  Up-Route  Flight  Plan  Database  with  the  Up-Route  flight  plans,  and  the 
Trial  Flight  Plan  Database  with  the  Trial  Flight  Plans. 

6.2  Inputs 

•  UP-ROUTE  PROBE_EXTEN_FP  -  Flight  Plan  sent  from  FP  ENTRY  SUPPORT  to 
UP-ROUTE7TRIAL  FP  PROC  to  be  stored  and  sent  to  FP  OPERATION  SUPPORT. 

•  UN-ROUTE  PROC_TRIAL_FP  -  Trial  FP  sent  from  FP  ENTRY  SUPPORT  to 
UP-ROUTE/TRIAL  FP  PROC  to  be  stored  and  sent  to  FP  OPERATION  SUPPORT  for  route  proc¬ 
essing. 


6.0  Flight  Plan  Entry  Support  123 


STARS  Deliverable  1200 


6.2  Outputs 

•  Flight  Plans  are  stored  in  the  appropriate  database. 


6.3  Flight  Plan  Update  Processing 

6.3  Description 

Flight  Plan  Update  Processing  receives  updates  to  times  in  a  flight  plan.  If  the  update  is  a  departure  time, 
Departure  Processing  is  called  to  update  the  time  and  move  the  flight  plan  from  the  Inactive  Flight  Plan 
Database  to  the  Active  Flight  Plan  Database.  If  the  update  is  a  fix  arrival  time,  Fix  Arrival  Processing  is 
called  to  modify  the  fix  arrival  time  in  the  flight  plan.  If  the  update  is  a  flight  plan  status  update,  Flight  Plan 
Status  Processing  is  called  to  modify  the  status  in  the  flight  plan.  In  each  of  the  above  cases,  the  updated 
Flight  Plan  is  sent  to  Flight  Plan  Operation  Support  for  further  processing.  Finally,  if  the  update  is  an 
actual  arrival  time,  Arrival  Processing  is  called  to  remove  the  flight  plan  from  the  Active  Flight  Plan  Data¬ 
base. 

6.3  Inputs 

•  NEW_FP_UPDATES  -  Flight  Plan  Updates  sent  from  FP  ENTRY  SUPPORT  to  FP  UPDATE 
PROC  to  be  stored  and  sent  to  FP  OPERATION  SUPPORT. 

6.3  Outputs 

•  TIME_UPDATES  -  FP  with  an  update  to  a  time  (departure,  arrival,  or  arrival  at  a  fix.)  Sent  from  FP 
UPDATE  PROC  to  FP  OPERATION  SUPPORT. 

•  DEPARTURE_TIME  UPDATE  -  Contains  departure  time  for  an  FP.  Sent  from  FP  UPDATE 
PROC  to  DEPART  PROC. 

•  FIX_ARRIVAL_TIME_UPDATE  -  Sent  from  FP  UPDATE  PROC  to  MODIFY  TIMES.  Contains 
actual  arrival  time  at  a  fix  in  the  flight  plan. 

•  ARRIVAL_TIME  UPDATE  -  Actual  arrival  time  for  the  flight  plan.  Sent  from  FLIGHT  PLAN 
UPDATE  PROCESSING  to  ARRIVAL  PROC. 

•  FLIGHT_PLAN_STATUS  UPDATE  -  New  status  for  an  FP.  Sent  from  FLIGHT  PLAN  UPDATE 
PROCESSING  to  FLIGHT  PLAN  STATUS  PROCESSING  to  be  updated  in  the  ACTIVE  FP  data¬ 
base. 


6.4  Handoff-ln  Processing 

6.4  Description 

When  Handoff-ln  Processing  receives  a  handoff-in  message  from  an  up-route  center,  or  when  it  determines 
that  a  handoff  within  the  center  is  required  (ie.  an  the  flight  plan  is  an  adapted  time  from  crossing  a  sector 
boundary),  it  calls  Notify  Controller  to  notify  the  controller  of  the  handoff.  When  the  controller  acknowl¬ 
edgement  of  the  handoff  is  received,  if  the  handoff  was  from  an  up-route  center,  Update  Up-Route  Database 
is  called  to  delete  the  flight  pian  from  the  Up-Route  Database.  Update  Flight  Plan  Status  is  called  in  any 
case,  to  update  the  handoff  time  in  the  flight  plan.  The  update  flight  plan  is  then  sent  to  Flight  Plan  Opera¬ 
tion  Support  for  further  processing. 
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6.4  Inputs 

•  HANDOFF-IN_DATA  -  Flight  Plan  from  which  handoff-in  processing  is  required.  Received  from  an 
up-route  center  and  sent  to  HANDOFF-IN  PROC. 

•  CONTROLLER  HANDOFF  IN  ACK  -  Controller  acknowledges  the  handoff-in.  Sent  from  FP 
ENTRY  SUPPORT  to  HANDOFF-IN  PROCESSING  > 

6.4  Outputs 

•  UP-ROUTE  HANDOFF  -  Up-Route  handoff  flight  plan  sent  from  HANDOFF-IN  PROC  to 
UPDATE  UP-ROUTE  DATABASE  to  be  deleted  from  the  UP-ROUTE  FP  database  and  added  to 
the  ACTIVE  FP  database. 

•  HANDOFFJTIME  -  Time  handoff  occurred.  Sent  from  HANDOFF-IN  PROC  to  UPDATE  FP 
STATUS  to  be  updated  in  the  ACTIVE  FP  database. 

•  HANDOFF-IN_CONTROLLER_DATA  -  Handoff-in  data  to  be  sent  to  the  controller.  Sent  from 
HANDOFF-IN  PROC  to  NOTIFY  CONTROLLER. 
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6.1  Initial  Flight  Plan  Processing  Discussion 

The  new  flight  plan  or  flight  plan  amendment  is  first  sent  to  Syntax  Checker.  If  it  contains  no  syntax 
errors,  it  is  sent  to  Geography  Checker.  If  it  contains  no  geography  errors,  it  is  returned  to  Initial  Flight 
Plan  Processing  to  be  stored  in  the  appropriate  flight  plan  database.  Errors  detected  by  these  processes  are 
also  returned  to  Initial  Flight  Plan  Processing. 

Bulk  flight  plans  are  sent  from  Initial  Flight  Plan  Processing  to  Bulk  Flight  Plan  Processing  to  be  stored  in 
the  flight  plan  database.  Initial  Flight  Plan  Processing  also  determines  when  a  bulk  flight  plan  must  be 
activated,  and  sends  it  to  Flight  Plan  Operation  Support.  Figure  44  on  page  128  presents  the  processing 
controlled  by  Initial  Flight  Plan  Processing. 
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6.1.1  Syntax  Checker 


6.1.1  Description 

Syntax  Checker  receives  a  flight  plan  message  from  Initial  Flight  Plan  Processing  and  validates  the  syntax  of 
the  message.  If  an  error  is  detected,  an  error  message  is  sent  to  Initial  Flight  Plan  Processing.  Otherwise, 
the  flight  plan  message  is  sent  to  Geography  Checker. 

6.1.1  Inputs 

•  UN-VALIDATED_FLIGHT_PLAN  -  Flight  Plan  which  has  not  been  syntax  or  geographically 
checked.  Sent  from"  INITIALFP  PROC  to  SYNTAX  Checker. 

6.1 .1  Outputs 

•  SYNTAX_ERROR  -  Error  found  by  SYNTAX  CHECKER  and  sent  to  INITIAL  FLIGHT  PLAN 
PROC. 

•  SYNTAX_CHECKED_FP  -  FP  which  has  been  syntax  checked  by  SYNTAX  CHECKER  and  is  being 
sent  to  GEOGRAPHY  CHECKER  to  be  checked  geographically. 

6.1.2  Geography  Checker 

6.1.2  Description 

Geography  Checker  validates  the  geography  in  the  flight  plan  message  received  from  Syntax  Checker.  If  the 
data  is  good,  the  flight  plan  message  is  returned  to  Initial  Flight  Plan  Processing.  Otherwise,  an  error 
message  is  sent  returned. 

6.1.2  Inputs 

•  SYNTAX_CHECKED_FP  -  FP  which  has  been  syntax  checked  by  SYNTAX  CHECKER  and  is  being 
sent  to  GEOGRAPHY  CHECKER  to  be  checked  geographically. 

6.1.2  Outputs 

•  GEOGRAPHY_ERROR  -  Error  detected  by  GEOGRAPHY  CHECKER  and  sent  to  INITIAL  FP 
PROC. 

•  SYNTAX_GEOGRAPHY_VALIDATED_FP  -  Flight  Plan  which  has  been  syntax  and  geographically 
checked.  Sent  from  GEOGRAPHY  CHECKER  to  INITIAL  FP  PROC. 


6.1.3  Bulk  Flight  Plan  Processing 

6.1.3  Description 

Bulk  Flight  Plan  Processing  receives  bulk  flight  plans  from  Initial  Flight  Plan  Processing.  The  flight  plans 
have  already  been  through  syntax  and  geography  processing.  The  flight  plans  are  stored  in  the  Bulk  Flight 
Plan  Database  until  an  adapted  time  prior  to  departure.  At  the  adapted  time,  the  flight  plan  is  retrieved 
from  the  database  and  sent  to  Flight  Plan  Operation  Support  for  further  processing. 

6.1.3  Inputs 

•  NEW_BULK_FLIGHT_PLAN  -  New  bulk  flight  plan,  sent  from  INITIAL  FP  PROC  to  BULK  FP 
PROC  to  be  stored  in  the  bulk  flight  plan  database. 
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6.1.3  Outputs 

•  INITLATED_BULK_FP  -  Bulk  flight  plan  which  is  X  minutes  from  departure.  (X  is  an  adapted 
value.)  Sent  from  BULK  FP  PROC.  to  FP  OPERATION  SUPPORT  for  route  processing. 
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6.3  Flight  Plan  Update  Processing  Discussion 

.  r 

When  Flight  Plan  Update  Processing  receives  a  departure  time,  Departure  Processing  is  called  to  update  the 
time  and  move  the  flight  plan  from  the  Inactive  Flight  Plan  Database  to  the  Active  Flight  Plan  Database. 
When  Flight  Plan  Update  Processing  receives  a  fix  arrival  time  update,  Fix  Arrival  Processing  is  called  to 
modify  the  fix  arrival  time  in  the  flight  plan.  When  Flight  Plan  Update  Processing  receives  a  flight  plan 
status  update,  Flight  Plan  Status  Processing  is  called  to  modify  the  status  in  the  flight  plan.  When  Flight 
Plan  Update  Processing  receives  an  actual  arrival  time  update,  Arrival  Processing  is  called  to  remove  the 
flight  plan  from  the  Active  Flight  Plan  Database.  Figure  45  on  page  132  presents  the  processing  controlled 
by  Flight  Plan  Update  Processing. 
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Figure  45.  6.3  Flight  Plan  Update  Processing  DFD.  This  figure  is  the  DFD  for  the  IOM  Object,  6.3  Flight  Plan 
Update  Processing. 
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6.3.1  Departure  Processing 

6.3.1  Description 

When  Departure  Processing  receives  an  actual  departure  time  from  Flight  Plan  Update  Processing,  it 
retrieves  the  flight  plan  from  the  Inactive  Flight  Plan  Database,  updates  the  actual  departure  time  in  the 
flight  plan,  and  stores  the  flight  plan  in  the  Active  Flight  Plan  Database.  If  the  update  is  to  the  estimated 
departure  time,  the  time  is  updated  in  the  Inactive  Flight  Plan  Database. 

6.3.1  Inputs 

•  DEPARTURE  TIME  UPDATE  -  Contains  departure  time  for  an  FP.  Sent  from  FP  UPDATE 
PROC  to  DEPART  PROC. 

6.3.1  Outputs 

•  DELETED  DEPARTURES  -  FPs  which  have  departed  are  deleted  from  the  INACTIVE  FP  by 
DEPARTURE  PROCESSING. 

•  NEW  DEPARTURES  -  Flight  plans  which  have  just  departed.  Stored  in  ACTIVE  FP  database  by 
DEPARTURE  PROCESSING. 

6.3.2  Fix  Arrival  Processing 

6.3.2  Description 

When  Fix  Arrival  Processing  receives  a  flight  plan  time  update  from  Flight  Plan  Update  Processing,  it 
updates  the  fix  arrival  time  in  the  flight  plan. 

6.3.2  Inputs 

-  FIX_ARRIVAL_TIME_UPDATE  -  Sent  from  FP  UPDATE  PROC  to  MODIFY  TIMES.  Contains 
actual  arrival  time  at  a  fix  in  the  flight  plan. 

6.3.2  Outputs 

•  UPDATED_FIX  ARRIVAL  TIMES  -  Actual  or  estimated  fix  arrival  time  updates  added  to  the 
ACTIVE  FP  database  by  MODIFY  TIMES. 

6.3.3  Arrival  Processing 

6.3.3  Description 

When  Arrival  Processing  receives  an  actual  arrival  time  from  Flight  Plan  Update  Processing,  it  deletes  the 
flight  plan  from  the  Active  Flight  Plan  Database.  If  the  update  is  to  the  estimated  arrival  time,  the  time  is 
updated  in  the  appropriate  flight  plan  database.  (The  flight  may  be  Active  or  Inactive.) 

6.3.3  Inputs 

•  ARRIVAL_TIME  UPDATE  -  Actual  arrival  time  for  the  flight  plan.  Sent  from  FLIGHT  PLAN 
UPDATE  PROCESSING  to  ARRIVAL  PROC. 
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6.3.3  Outputs 

•  DELETED_ARRIVALS_ESTIMATED_ARRIVAL_TIME_UPDATE  -  Arrivals  which  are  deleted 
from  the  ACTIVE  FP  database,  or  whose  estimated  time  of  arrival  are  modified  in  the  ACTIVE  FP 
database  by  ARRIVAL  PROC. 

•  ESTIMATED  TIME_ARRIVAL_UPDATES  -  Estimated  time  of  arrival  updates  to  be  made  to  the 
INACTIVE  FP  database  by  ARRIVAL  PROC. 


6.3.4  Flight  Plan  Status  Processing 

6.3.4  Description 

When  Flight  Plan  Status  Processing  receives  an  update  to  a  flight  plan  status,  it  updates  the  status  of  the 
flight  plan  in  the  Active  Flight  Plan  Database. 

6.3.4  Inputs 

•  FLIGHT_PLAN_STATUS_UPDATE  -  New  status  for  an  FP.  Sent  from  FLIGHT  PLAN  UPDATE 
PROCESSING  to  FLIGHT  PLAN  STATUS  PROCESSING  to  be  updated  in  the  ACTIVE  FP  data¬ 
base. 

6.3.4  Outputs 

•  UPDATED_STATUS  -  Status  updates  to  an  FP  (FREE  or  FLAT). 
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6.4  Handoff-ln  Processing  Discussion 

Notify  Controller  is  triggered  when  Handoff-ln  Processing  receives  a  handoff-in  message  from  an  up-route 
center,  or  when  it  determines  that  a  handoff  within  the  center  is  required  (ie.  an  the  flight  plan  is  an  adapted 
time  from  crossing  a  sector  boundary).  Update  Up-Route  Database  is  triggered  when  the  controller 
acknowledgement  of  the  handoff  is  received  by  Handoff-ln  Processing,  and  the  handoff  was  from  an  up- 
route  center.  Update  Flight  Plan  Status  is  triggered  to  update  the  handoff  time  in  the  flight  plan.  The 
update  flight  plan  is  then  sent  to  Flight  Plan  Operation  Support  for  further  processing.  Figure  46  on 
page  136  presents  the  processing  controlled  by  Handoff-ln  Processing. 
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Figure  46.  6.4  HandofT-ln  Processing  DFD.  This  figure  is  the  data  flow  diagram  for  the  IOM  Object,  6.4  HandofT-In 
Processing. 
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6.4.1  Update  Up-Route  Database 

6.4.1  Description 

Update  Up- Route  Database  is  called  when  the  controller  acknowledges  a  handoff  from  an  up-route  center. 

If  the  flight  plan  is  in  the  Up-Route  Flight  Plan  Database,  it  is  deleted  from  that  database  and  moved  to  the 
Active  Flight  Plan  Database. 

6.4.1  Inputs 

•  UP-ROUTE_HANDOFF  -  Up-Route  handoff  flight  plan  sent  from  HANDOFF-IN  PROC  to 
UPDATE  UP-ROUTE  DATABASE  to  be  deleted  from  the  UP-ROUTE  FP  database  and  added  to 
the  ACTIVE  FP  database. 

6.4.1  Outputs 

•  DELETED  UP-ROUTE_FP  -  FP  to  delete  from  UP-ROUTE  FP  database  because  it  has  moved  into 
this  area.  Sent  from  UPDATE  UP-ROUTE  PROC. 

•  UP-ROUTE  FP_IN  AREA  -  UP-Route  FP  which  has  arrived  in  this  area.  Sent  to  ACTIVE  FP  data¬ 
base  by  UPDATE  UP-ROUTE  database. 

6.4.2  Update  Flight  Plan  Status 

6.4.2  Description 

Update  Flight  Plan  Status  is  triggered  when  the  controller  acknowledges  a  handoff.  The  handoff  time  is 
updated  in  the  Active  Flight  Plan  Database.  The  updated  time  is  then  sent  to  Flight  Plan  Operation 
Support  for  further  processing. 

6.4.2  Inputs 

•  HANDOFF_TIME  -  Time  handoff  occurred.  Sent  from  HANDOFF-IN  PROC  to  UPDATE  FP 
STATUS  to  be  updated  in  the  ACTIVE  FP  database. 

6.4.2  Outputs 

•  HANDOFF-IN_TIME  -  Time  that  handoff  into  this  area  occurred.  Updated  in  ACTIVE  FP  database 
by  UPDATE  FP  STATUS. 

•  HANDOFF_TIME_UPDATE  -  Time  of  handoff-in.  Sent  from  UPDATE  FP  STATUS  to  FP  OPER¬ 
ATION  SUPPORT  for  further  processing. 

6.4.3  Notify  Controller 

8.4.3  Description 

Notify  Controller  is  called  when  a  handoff-in  request  is  received  from  an  up-route  center,  or  when 
Handoff-in  Processing  detects  that  a  flight  plan  is  within  and  adapted  time  from  crossing  a  sector.  Notify 
Controller  indicates  to  the  controller  the  flight  plan  and  its  location. 

6.4.3  Inputs 

•  HANDOFF-IN_CONTROLLER  DATA  -  Handoff-in  data  to  be  sent  to  the  controller.  Sent  from 
HANDOFF-IN  PROC  to  NOTIFY  CONTROLLER. 
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6.4.3  Outputs 

•  HANDOFF-IN_ACK_REQUEST  -  Acknowledge  request  sent  from  NOTIFY  CONTROLLER  to 
AREA  CONTROL  to  acknowledge  a  handoff-in. 
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When  a  handoff-in  request  is  received,  or  when  a  flight  plan  is  X  minutes  (X  is  an  adapted  value)  from 
arrival  into  a  sector  in  this  area,  Notify  Controller  is  triggered.  When  the  controller  acknowledgement  of  the 
handoff  is  received  by  Hand  off- In  Processing,  and  the  handoff  was  from  an  up-route  center,  Update  Up- 
Route  Database  is  triggered,  followed  by  Update  Flight  Plan  Status.  When  the  controller  acknowledgement 
of  the  handoff  is  received  by  Handoff-In  Processing,  and  the  handoff  was  from  within  the  center,  only 
Update  Flight  Plan  Status  is  triggered.  Figure  47  on  page  140  presents  the  processing  performed  by 
Handoff- In  Processing. 

6.4  States 

•  KSQ01  -  IDLE 

-  IDLE 

•  KS002  -  NOTIFYING_CONTROLLER 

-  Notifying  controller  of  a  handoff-out. 

•  KS003  -  PERFORMING  DATABASE  UPDATES 

-  Removing  the  flight  plan  from  the  UP-ROUTE  database  and  adding  it  to  the  ACTIVE  database. 

•  KS004  -  PERFORMING  FLIGHT  PLAN  UPDATES 

-  Updating  the  Handoff  times  in  the  flight  plan. 

6.4  Transition  Vectors 

•  KTF02  -  CONTROLLER  NOTIFIED 

-  CONDITION  :  CONTROLLER  NOTIFIED 

-  ACTION: 

•  KS004  -  DATABASE_DONE_UPDATE_TIME 

-  CONDITION  :  DATABASE  UPDATES  COMPLETE 

-  ACTION  :  UPDATE  HANDOFF  TIME 

•  KTF03  -  FP  FROM  UP-ROUTE  AREA 

-  CONDITION  :  FP  FROM  UP-ROUTE  AREA,  CONTROLLER  HANDOFF-IN  ACK 

-  ACTIONS  :  DELETE  FROM  UP-ROUTE  DATABASE,  ADD  TO  ACTIVE  FP  DATABASE 

•  KS006  -  HANDOFF_FROM_INSIDE_AREA 

-  CONDITION  :  FP  FROM  INSIDE  AREA,  CONTROLLER  HANDOFF-IN  ACK 

-  ACTION  :  UPDATE  HANDOFF  TIME 

•  KTF01  -  HANDOFF_IN_RECEIVED 

-  CONDITION  :  RECEIVED  HANDOFF-IN  REQUEST 

-  ACTION  :  NOTIFY  CONTROLLER 

•  KS005  -  UPDATES  COMPLETE 

-  CONDITION  :  UPDATES  COMPLETE 

-  ACTION: 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  6.0  Flight 
Plan  Entry  Support. 

"Flight  Plan  Entry  Support"  Information  Flows 

The  following  report  identifies  the  inputs  to  and  outputs  from  each  of  the  functional  objects  in  the  Flight 
Plan  Entry  Support  object. 
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''All  Data  Flows*  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  flows  for  the  Flight  Plan 
Entry  Support  object. 
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Nats 

Alternate  Nate 

Short  Descrip. 

Last  Modify  Date 

K0036 

ARRIVAL  TIME  UPDATE 

Actual  arrival  tiae  for  the  fliqht  plan.  Sent  fro« 

FP  UPDATE  PROC  to  ARRIVAL  PROC. 

900116 

K0009 

CONFLICT  DATA 

Fliqht  Plans  with  updated  conflict  data.  Lsqqed  in  active 

FP  database  by  Update  Fix  Data. 

900110 

K0062 

CONFLICT  SITUATIONS 

Conflict  situations  received  fro*  FP  TRACKING  ANALYSIS. 

Sent  to  UPDATE  FIX  DATA  to  store  with  trajectory  data. 

391216 

K0054 

CONTROLLER  ACK  HANDOFF-OUT 

Indication  fro«  FP  OPER  SUPP  to  FP  STRIP/HANDOFF  FROC  that 
the  controller  acknowledged  the  handoff-out. 

900105 

KC059 

CONTROLLER  HANDOFF-OUT  ACK 

Ack  sent  fro«  STRIP/HANDDFF  to  HANDOFF-CUT  PROC  to  indicate 
controller  acknowledged  handoff-out. 

900105 

K0051 

CONTROLLER  HANDOFF  IN  ACK 

Controller  acknowledges  the  handoff-in.  Sent  froa  FP  ENTRY 
PROC  to  HANDOFF-IN  PROC. 

900104 

K0039 

DELETED  ARRIVALS  EST  ARR  TM  UPDT 

Arrivals  which  are  deleted  fro#  the  ACTIVE  FP  database  or 
whose  ETA  are  updated  by  ARRIVAL  PROC. 

900116 

K0040 

DELETED  DEPARTURES 

FPs  which  have  departed  are  deleted  froa  the  INACTIVE  FP  by 
DEPARTURE  PROCESSING. 

900104 

K0043 

DELETED  UPROUTE  FP 

FP  to  delete  froa  UP-Route  FP  database  because  it  has  aoved 
into  the  area.  Sent  froa  UPDATE  UPROUTE  DATABASE. 

900104 

K0061 

DELETE  HANDOFF-OUT  FP 

Delete  the  fp  that  was  handoff-out  processed  froa  the 

ACTIVE  FP  database  for  this  area. 

900105 

K0032 

DEPARTURE  TIME  UPDATE 

Contains  departure  tine  for  an  FP.  SEnt  froa  FP  UPDATE 

PROC  to  DEPART  PROC. 

900104 

K0047 

ESTIMATED  TIME  ARRIVAL  UPDATES 

Estiaated  tiae  of  arrival  uooates  to  be  aade  to  inactive 
flight  clan  database  by  ARRIVAL  PROCESSING. 

900111 

>10033 

FIX  ARRIVAL  TIME  UPDATE 

Sent  froa  FP  UPDATE  PROC  to  MODIFY  TIMES.  Contains  actual 
arrival  tiae  at  a  fix  in  the  fliont  plan. 

900109 

-.C02S 

-LIGHT  PLAN  AMENDMENT 

FP  anenonent  sent  froa  FP  ENTRY  SUPPORT  to  INITIAL  FP  PROC. 
to  oe  syntax/qeoq.  checked  and  stored. 

900104 

«GOi5 

-LIGHT  PLAN  CHANGES 

Flight  Plan  with  chanoes.  sent  fr on  UPDATE  FIX  DATA  to 
PREDICTION  AND  RESOLUTION  for  analysis  of  the  chanoes. 

900105 

m)b 

FLIGHT  PLAN  ENTRY  LOG  DATA 

Data  logged  by  FLIGHT  PLAN  ENTRY  SUPPORT. 

900104 

K0005 

FLIGHT  PLAN  OPERATION  LOG  DATA 

Data  logged  cy  FLIGHT  PLAN  OPERATION  SUPPORT. 

900105 

K0064 

FLIGHT  PlAN  STATUS  UPDATE 

New  status  for  an  F°.  Sant  froa  FF  UPDATE  PROC  to  FP  STATUS 
PROCESSING  to  be  updated  i,t  the  active  F5  database. 

300116 
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Hare 

Alternate  Na«e  * 

Short  Descrip. 

Last  Modify  Date 

K0004 

FLIGHT  PLAN  STRIPS  HANDOFF-QUT 

Strips  containinq  FP  data.  Sent  froa  STRIP/h'ANDOFF  to  AREA 
CONT  an  adapted  tiae  prior  to  ~1 iaht  arr  in  that  area/sector 

900116 

KOOOl 

FP3  AKEND  UPDT  TRIAL  ERRORS 

FP  data  sent  to  FLIGHT  PLAN  ENTRY  SUPPORT.  Includes  new  FPs, 
aaendaents,  updates,  trial  FPs,  &  handoffs.  Errors  returned 

900116 

KCOIO 

FP  CHANGES  CONFLICT  SITUATIONS 

Chanqes  created  to  a  fliqht  plan  which  require  PREDICTION  i 
RESOLUTION  to  run,  and  the  results  of  the  run. 

900105 

M03 

FP  EVENT  STATUS 

Fliqht  Plan  Event,  such  as  fix  crossinqs,  and  status,  such 
as  nonconforaance  reports. 

900119 

mis 

FP  METERING  DATA 

Meterinq  data  for  the  FP,  sent  froa  GEN  NET.  TIMES  to 

UPDATE  FIX  DATA  so  it  can  pass  the  data  to  the  appro,  place. 

900105 

K0017 

FP  NEEDING  METERING 

FP  sent  froa  UPDATE  FIX  DATA  to  GENERATE  METERABLE  TINES 
for  the  purpose  of  calculatinq  aeterinq  for  its  fixes. 

900105 

K0911 

'P  HITHOUT  ROUTE  DATA 

Fliqht  plan  passed  froa  FP  OPERATION  to  EXPAND  ROUTE  for 
the  purpose  of  coapletinq  the  fixes  in  the  route. 

900105 

K0015 

FP  HITHOUT  TRAJECTORY 

FP  sent  froa  UPDATE  FIX  DATA  to  CREATE  TRAJECTORY  for  the 
purpose  of  fillinq  in  the  trajectory  data. 

900105 

K0003 

FP  WITH  ROUTE  DATA 

Fliqht  clan  sent  froa  EXPAND  ROUTE  to  UPDATE  FIX  DATA. 

900105 

<00iS 

FP  WITH  TIKE  UPDATES 

Fliqht  plan  which  has  had  a  tine  aodified  and  requires  a 
new  trajectory  and  fix  aeterinq  calculations. 

900115 

K'OOIS 

FP  ilITH  TRAJECTORY  DATA 

FP  sent  froa  CREATE  TRAJECTORY  to  UPDATE  FIX  DATA  after  the 
trajectory  data  has  been  provided. 

900105 

LOGS  I 

GEOGRAPHY  ERROR 

Error  detected  by  GEOGRAPHY  CHECKER  and  sent  to  INITIAL  FP 
PROC. 

900104 

.<0)53 

HANDOFF-IN  ACL  REQUEST 

Ackncwledqe  request  sent  froa  NOTIFY  CONTROLLER  to  AREA 
CONTROL  to  acknowiedqe  a  handoff-in. 

900104 

Kf  056 

HANDOFF -ObT  iNITIATET  DATA 

Data  froa  INITIATE  HAHDGFF-QUT  to  5TRIP/HAND0FF  PROC  to  be 
sent  to  the  controller. 

900115 

\0052 

HANDOFF-OUT  INIT  REQUIRED 

indication  froa  F?  OPER  SUPP  to  STSIP/HAHDCFF  PROC  that  it 
is  tine  to  initiate  a  handoff-out. 

900105 

S0055 

HANSOFF-OJT  NEEDED 

STRIP/HANDOFF  Proc  initiates  INITIATE  HANDOFF  with  this 
indication  that  a  handoff-out  is  needed. 

900105 

-A ! 

hANDOFF  IN  DATA 

Fliqnt  plan  for  wmch  handoff-in  processmq  is  required. 

900104 

l-'-iinZ 

HANDOFF  IN  TIKE 

T':r.e  that  handoff  into  this  area  occurred.  Updated  in 

ACTIVE  FP  database  by  UPDATE  :P  STATUS. 

900104 

DATE: 

TIMHi 

24-APR-90 

19:23 
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Naae 

Alternate  Naae 

Short  Descrip. 

Last  Modify  Date 

K0042 

HANDDFF  TIME  UPDATE 

Tiae  of  handoff-in.  Sent  froa  UPDATE  FP  STATUS  to  FP  OPER 
SUPPORT  for  further  processinq. 

900104 

K00E9 

INITIAL  FP  PROC  ERRORS 

Errors  sent  froa  INITIAL  FP  PROC.  to  FP  ENTRY  SUPPORT  which 
Mere  detected  durinq  syntax  or  qeoqraphy  checkinq. 

891215 

K0019 

INITIATED  BULK  FP 

Bulk  fliqht  plan  which  is  X  ain.  froa  departure.  Sent  froa 
BULK  FP  PROC.  to  FP  OPERATION  for  route  orocessinq. 

900104 

KOOEO 

NEW  BULK  FLIGHT  PLAN 

New  bulk  fliqht  plan,  sent  froa  INITIAL  FP  PROC  to  BULK  FP 
PROC  to  be  stored  in  the  bulk  fliqht  plan  database. 

900104 

K0037 

NEW  DEPARTURES 

Fliqht  plans  which  have  just  departed.  Stored  in  ACTIVE  FP 
database  by  DEPARTURE  PROCESSING. 

9C0104 

K0027 

NEW  FLIGHT  PLAN  HESSASE 

New  fliqht  plan  aessaqe  sent  froa  FP  ENTRY  SUPPORT  to 

INITIAL  FP  PROC.  to  be  syntax/qeoq.  checked  and  stored. 

900104 

K00&8 

HEW  FPS  AMENDS  TRIALS  ERRORS 

FP  data  received  froa  FLIGHT  SERVICE  DATA  PROC,  TOWER 

CONTROL  FACILITY,  OCEANIC  FLIGHT  PLAN  PROC,  or  AREA  CONTROL. 

900103 

K0034 

NEW  FP  UPDATES 

Fliqht  plan  updates  sene  froa  FP  ENTRY  SUP?  to  FP  UPDATE 

PROC  to  be  stored  and  sent  to  F?  OPER  3UPP. 

900104 

K0046 

PROSE  EXTENSION  REQUEST 

Request  froa  an  up-rcute  center  for  a  probe  extension. 

900119 

KCOO? 

ROUTE  ERRORS 

Errors  in  the  route  of  a  FP.  Detected  by  EXPAND  ROUTE. 

Sent  to  the  oriqinator  of  the  fliqht  plan. 

900105 

.‘'0050 

RULES  AND  REGS 

Rules  or  requlations  set  up  by  the  FAA  neadauaters, 
specifinq  lisits  within  which  the  ATC  is  to  function. 

900119 

K005S 

STRIP  DATA 

Strip  data  sent  froa  GEN  STRIP  to  STRIP/HANDOFF  PROC  for 
distribution  to  the  appropriate  control ier/area. 

900105 

K0057 

STRIP  NEEDED 

Indication  froa  STRIP/HANDOFF  PROC  to  GEN  STRIP  that  a 
strip  is  needed. 

900105 

.50:3 

STRIP  REQUIRED 

Indication  froa  FP  OPERATION  to  STRIP/HANDOFF  PROCESSING 
that  a  atrip  is  required. 

900105 

.<0025 

SYNTAX  CHECKED  rP 

FP  xnich  has  been  syntax  checked  oy  SYNTAX  CHECKER  and  is 
beinc  sent  to  GEQG  CHECKER  to  be  decked  qeooraphicf.il/. 

900104 

;0C22 

SYNTAX  ERROR 

Error  found  2y  SYNTAX  CHECKER  and  sent  to  INITIAL  FLIGHT 

PLAN  PF.OC. 

90010* 

j  0023 

SYNTAX  -3EQ3  VALIDATED  F3 

:liqht  plan  which  has  been  syntax  and  qeoqraphicaiiy 
checked.  Sent  froa  GEOG  CHECK  to  INITIAL  F?  PROC. 

900104 

** 

TINE  UPDATES 

FP  with  an  update  to  a  tiae  (departure,  arrival,  or  arrival 
at  a  fix.)  Sent  froa  FP  UPDATE  PROC  to  FP  OPER  SUPP. 

900104 

DATE:  26-APR-90 
TIME:  19:83 


t»*  • 
*** 
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Naie 

Alternate  Naie 

Short  Descrip. 

Last  Modify  Date 

K0031 

■JNROUTE  PROC  TRIAL  FP 

Trial  FP  sent  fro*  FP  ENTRY  SUPP  to  UP-ROUTE/TRIAL  FP  PROC 
to  be  stored  and  sent  to  FP  OPER  SUPP  for  route  processing. 

9C0104 

K0024 

UHVALIDATED  FLIGHT  PLAN 

Fliqht  Plan  which  has  not  been  syntax  or  geographically 
checked.  Sent  froa  INITIAL  FP  PROC  to  SYNTAX  CHECKER. 

900104 

K0030 

UP-ROUTE  PROBE  EXTEN  FP 

Fliqht  plan  sent  froa  FP  ENTRY  SUPP  to  UP-RQUTE/TRIAL  FP 

PROC  to  be  stored  and  sent  to  FP  OPER  SUPPORT. 

900104 

K0C38 

UPDATED  FIX  ARRIVAL  TINES 

Actual  or  estiaated  fix  arrival  tiee  updates  added  to  the 
ACTIVE  FP  database  by  MODIFY  TINES. 

900110 

.<0043 

UPDATED  STATUS 

Status  updates  to  an  FP  (FREE  or  FLAT). 

900104 

K0044 

UP  ROUTE  FP  IN  AREA 

Up-route  FP  which  has  arrived  in  this  area.  Sent  to  ACTIVE 
FP  DATABASE  by  UPDATE  FP  STATUS. 

900116 

'0002 

VALIDATED  FLIGHT  PLANS 

FPs  sent  fro*  FP  ENTRY  SUPP.  to  FP  OPER.  SUPP..  FPs  have 
been  syntax  &  geog.  checked.  Need  route  processing. 

900116 

K0026 

HEATHER  SURV  INFO 

Heather  snforaation  in  the  fori  of  radar  data  and  reports 
on  pressure,  winds  aloft,  temperature,  etc. 

900119 
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"All  Records  and  their  Elements"  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  the  records  and  their  elements 
for  the  Flight  Plan  Entry  Support  object. 
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DATE:  24-APR-90 

TIME:  19:25 

• 

.  ,.y  Kate 

m  ALL  RECORDS  FOR  m  PAGE  1 

#**  FLIGHT  PLAN  PROCESSING  **»  EXCEL/RTS 

=(  ELE/REC  Na»e  >+  Definition 

ARRIVAL  TIME  UPDATE 

=  FLIGHT  PLAN  ID 

ARRIVAL  TINE 

+  Update  to  the  liie  of  arrival  in  a  flight  plan. 

CONTROLLER  ACK  HANDOFF  OUT 

=  FLIGHT  PLAN  ID 

Indicates  fliqht  plan  for  which  handoff-out  was  acknowlea 

CONTROLLER  HANDOFF  IN  ACK 

=  FLIGHT  PLAN  ID 

Acknowledgement  of  handoff-in  froa  AREA  CONTROL. 

DELETED  ARRIVALS  EST  ARR  TH  UPDT 

=(  FLIGHT  PLAN  ID 

!+  FP  id  for  arrivals  to  delete  or  est  arrival  tiae. 

I  ARRIVAL  TIME 

) 

DEPARTURE  TIME  UPDATE 

=  FLIGHT  PLAN  ID 

DEPARTURE  TINE 

+  Update  to  the  departure  tise  in  a  fliqht  plan. 

FIX  ARRIVAL  TINE  UPDATE 

=  FLIGHT  PLAN  ID 

FIX  ARRIVAL  TINE 

+  Update  to  a  fix  arrival  tiae  in  a  fliqht  plan. 

FLIGHT  PLAN 

=  FLIGHT  PLAN  ID 

+  Entered  prior  to  fliqht.  Describes  route,  speed,  alt. 

AIRCRAFT  DATA 

f 

SPEED 

+ 

DEPARTURE  LOCATION 

+ 

AS3ISNED/REQUESTED  ALTITUDE 

+ 

ROUTE  DATA 

t 

#' 

REMARKS 

FLIGHT  PLAN  ENTRY  LOG  DATA 

*f  INITIAL  FLIGHT  PLAN  PROC  RESULTS  >+  Data  loqqed  by  FLIGHT  FLAN  ENTRY  SUPPORT. 

(  UP-ROUTE  FLIGHT  PLAN  RECEIVED 

It 

1  TRIAL  FLIGHT  PLAN  RECEIVED 

)+ 

(  FLIGHT  PLAN  UPDATE  PROC  RESULTS 

1+ 

f  HANDGFF-1N  PROC  RESULTS 

) 

FLIGHT  PLAN  METERING  DATA 

=!  FIX 

+  List  of  fixes  and  estimated  tiae  of  arrival. 

ESTIMATED  TINE  OF  ARRIVAL 

) 

FLIGHT  PLAN  OPERATION  LOG  DATA 

=(  EXPAND  ROUTE  LOG 

)+  Data  loqqed  durir.q  fliqht  plan  operations. 

(  UPDATE  FIX  DATA  LOG 

)+ 

i  STRIPS  LOS 

if 

!  HANDOFF  LOG 

) 

FLIGHT  FLAN  STATUS  UPDATE 

=  FLIGHT  PLA. 

FLIGHT  PLAN  STATUS 

f  Update  to  a  fliqht  plan  status. 

FLIGHT  FLAN  STRIPS  HANDOFF-QUT 

=(  STRIP  DATA 

)+  Info  *"rcs  STRIF7HANOOFF  PROC  to  AREA  CONTROLLER. 

!  HANDOFF-GUT  INITIATED  DATA 

) 

F-.IGHT  PLAN  UPDATE 

=  FLIGHT  PLAN  ID 

*  Update  to  a  fliqht  pian. 

(  DEPARTURE  TINE 

)+ 

!  FIX  ARRIVAL  TIKE 

)f 

I  ARRIVAL  TINE 

it 

• 

!  FLIGHT  PLAN  STATUS 

)t 

DATE:  2E-APR-90 
TIME:  19:25 


Hi 

Hi 


ALL  RECORDS  FOR 
FLIGHT  PLAN  PROCESSING 


t*i 

iii 
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Naae 

=(  ELE/REC  Naae 

)*  Definition 

FFS  AMEND  UPDT  TRIAL  ERRORS 

=(  FLI6HT  PLAN 
(  FLIGHT  PLAN  AMENDMENT 
(  FLIGHT  PLAN  UPDATE 
(  TRIAL  FLIGHT  PLAN 
(  CONTROLLER  ACH  HANDOFF  IN 
(  INITIAL  FP  PRQC  ERRORS 

it  FP  data  free  AREA  CNTL  to  FF  ENTRY,  !.  error  ssqs 

It 

)+ 

)+ 

)i 

\ 

FP  CHANGES  CONFLICT  SITUATIONS 

=(  FLIGHT  PLAN 
!  CONFLICT  SITUATIONS 

)+  Pipe  froe  Flight  Plan  Ooerations  to  Prediction  5  fiesoi. 

) 

HANDQFF-IN  ACK  REQUEST 

=  FLIGHT  PLAN  ID 

FLIGHT  LOCATION 

+  Request  for  controller  to  acknowledge  handoff. 

HANDOFF-QUT  INITIATED  DATA 

=  FLIGHT  PLAN  ID 

FLIGHT  LOCATION 

*  Sent  to  controller  to  indicate  a  handoff-eat  needed. 

HANDGFF-QUT  INIT  REQUIRED 

=  FLIGHT  PLAN  ID 

FLIGHT  LOCATION 

+  Data  to  indicate  which  flight  is  to  ce  handed  out. 

HANDOFF-QUT  NEEDED 

=  FLIGHT  PLAN  ID 

FLIGHT  LOCATION 

t  Indication  to  qeneraie  a  hsndoff-out. 

HANDOFF  IN  DATA 

=  FLIGHT  PLAN  ID 

FLIGHT  LOCATION 

+  Flight  Plan  id  and  loc.  for  handoff  flight. 

HANDOFF  TIME  UPDATE 

=  FLIGHT  PLAN  ID 

HANDOFF  IN  TIME 

+  Handoff  tiae  to  be  updated  in  a  fliqr.t  plan. 

INFIAL  FP  ?ROC  ERRORS 

=(  SYNTAX  ERROR 
(  GEOGRAPHY  ERROR 

)  Errors  found  in  initial  fp  checking.  Sent  to  AREA  CNTL. 

* 

STRIP  DATA 

FP  data  printed  at  each  sector  m  the  flaunt  plan. 

TINE  UPDATES 

=(  ARRIVAL  TIME  UPDATE 
(  DEPARTURE  TIME  UPDATE 
{  FIT  ARRIVAL  TIME  UPDATE 
(  FLIGHT  PLAN  STATUS  UPDATE 

!i  Updates  to  anv  of  the  tiaes  or  the  status  in  a  fhcht  pi 
)+ 

)+ 

) 

♦«  ALL  ELEMENTS  -  _E=HO 


PASS  1 
EXCEL/ RTS 


DATES  18-JAN-90 
^.Es  tl«£3 

2 


Oifimibr. 


ARRIVAL  TIRE 
DEPARTURE  TIRE 
ESTIRATED  TIRE  OF  ARRIVAL 
FIX 

FIX.ARRIVAL.TIHE 

FLliHT  PLAN  ERROR  RSSSASE 

rLI6HT.PLAN.ID 

FLI6HT.FLANJTATU3 

6E*j5P.-?HY_ESR0R 

FANSCFF'Ih.TIHE 

HAND2FFJM  TIRE 

ROUTE  ERRORS 

3V*1TS\  ERROR 


lisa  of  arrival  a;  :*s  destination. 

Tise  of  seoarture. 

Sat  bated  ?i2»  :f  arrival  ai  a  fix  or  destination. 
•Jiiwi  bcation  used  for  *outa  diternination  in  fos. 
Arrival  tice  at  a  ssacif tea  fix. 

Ressage  sent  is  AREA  CONTROL  indicating  error  ir.  fp. 
L'lioueiy  oefir.ee  a  "non:  olan. 

Status  of  an  active  *li;n;  clan. 

Error  four,:  ir  C*EOGSA?Hv  CHECKINS. 

Tisi  -andoff  into  the  sector/cantar  occurred. 

Errors  detected  during  *sut(  processing. 

Error  found  during  SYNTAX  CHECXIha. 
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'All  Data  Stores'  Report 

6.0  Flight  Plan  Entry  Support  employs/derives  the  following  globally  defined  data  stores  defined  in  Appendix 
A  of  this  document: 

•  AIRCRAFT_AND_ENVIRONMENT_DATA(employs) 

•  FLIGHT_PLANS  (employs/derives/updates). 
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'All  Control  Flows'  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  control  flows  for  the  Flight  Plan 
Entry  Support  object. 
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DATE:  25-AFR-90 
TIME:  15:34 


a*  CONTROL  FLOWS  -  LESHO  ««* 


PAGE  1 
EXCEL/RTS 


'/]  Naie  Alternate  Naae 

f/  .......  ....  r _ _ 

KCF03  HA  'GFF-IN  CONTROLLER  DATA 

KCF02  HANDOFF  TIME 

KCFOl  UPROUTE  HANDOFF 


Short  Descrip.  Last  Modi 


Handoff-in  data  to  be  sent  to  the  controller.  Sent  froa 
HANDQFF-IN  Proc  to  NOTIFY  CONTROLLER. 

Tiae  handoff  occurred.  Sent  fro*  HANDOFF  PROC  to  UPDATE  FP 
Status  to  be  updated  in  the  active  fp  database. 

Up-route  handoff  fp  sent  froa  HANDOFF  PROC  to  UPDATE 
UP-ROUTE  DB  to  be  deleted  froa  upr.  db ,  &  added  to  act,  db. 


1 


fy  Date 
891216 

891215 

891215 


DATE:  35-APR-90 
TIME:  15:34 


***  ALL  CONTROL  TRANSFORMS  -  LEHSQ  m 


PA6E  1 
EXCEL/RTS 


Alternate  Naie 


HAND OFF- IN  PROCESSINB 


Lonq  Description 

HANDOFF-IN  PROCESSINB  perforas  the  follouinq  : 

-  If  input  is  handoff-in  data,  call  NOTIFY  CONTROLLER. 

-  If  input  is  controller  ackmwledqeaent  of  handoff,  do  : 

-  If  handoff  is  froa  an  up-route  area,  triqqers  UPDATE  UP-ROUTE 
database  to  delete  it  froa  the  UP-ROUTE  FP  database  and  add  it  to  the 
ACTIVE  FP  database. 

-  Triqqer  UPDATE  FP  STATUS  to  update  the  handoff  tiae  in  the  fp  and  send 
the  fp  to  FP  OPER  SUPP  for  further  processino. 
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7.0  Flight  Plan  Operation  Support 

Introduction 

Flight  Plan  Operation  Support  processes  the  flight  plan  data.  It  receives  validated  flight  plans  from  Flight 
Plan  Entry  Support  whenever  a  flight  plan  has  been  modified  or  added  to  the  system.  It  expands  the  route 
in  the  flight  plan,  creates  a  trajectory  for  the  flight,  and  generates  the  estimated  time  of  arrival  for  meterable 
fixes  in  the  route.  Flight  Plan  Operation  Support  also  scans  the  Active  Flight  Plan  Database  periodically  to 
determine  when  a  strip  is  required,  or  when  a  handoff  out  of  the  system  is  going  to  occur. 

The  FLIGHT  PLAN  OPERATIONS  SUPPORT  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Flight  Plan  Operations  Support  View  From 

•  The  Flight  Plan  Operations  Support  Interfaces 

•  The  Flight  Plan  Operations  Support  Functional  Object  Tree 

•  Flight  Plan  Operations  Support. 

7.0  Flight  Plan  Operation  Support  "View  From" 

Validated  flight  plans  are  received  from  Flight  Plan  Entry  Support.  After  they  have  been  processed,  they  are 
stored  in  the  appropriate  flight  plan  database  (active  or  inactive),  and  also  sent  to  Prediction  and  Resolution 
for  further  processing.  Flight  Plan  Operations  Support  information  is  used  by  Flight  Plan  Operation 
Support  when  creating  the  trajectory.  Handoffs  and  strip  data  are  sent  from  Flight  Plan  Operation  to  Area 
Control.  Figure  48  on  page  147  presents  DOD  AAS  from  the  view  of  the  Flight  Plan  Operation  Support 
process. 
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Figure  48.  DoD  A  AS  View  From  Flight  Plan  Operation  Support.  This  Figure  highlights  the  Flight  Plan  Operation 

Support  functional  object  and  shows  the  flow  of  information  to  and  from  the  other  functional  objects  in  the 


DoD  A  AS  ATC  Model. 
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7.0  Flight  Plan  Operation  Support  Interfaces 

Flight  Plan  Operation  Support  receives  validated  flight  plans  (ie.  syntax  and  geographic  data  have  been  veri¬ 
fied)  from  Flight  Plan  Entry  Support.  Expand  Route  is  called  to  expand  the  route  data  in  the  flight  plan.  If 
no  errors  in  the  route  are  found,  Update  Fix  Data  is  called  to  create  a  trajectory  and  generate  the  estimated 
time  of  arrival  for  meterable  fixes. 

Flight  Plan  Operations  Support  also  scans  the  Active  Flight  Plan  Database  periodically  to  determine  any 
processing  that  is  required.  If  a  strip  is  required,  Flight  Plan  Operations  calls  Strip/Handoff  Processing  to 
create  the  strip  and  send  it  to  the  appropriate  controller.  If  a  flight  plan  is  within  an  adapted  time  from 
crossing  a  sector  or  center  boundary,  Strip/Handoff  Processing  is  called  to  initiate  the  handoff.  When  the 
controller  acknowledges  the  handoff,  Flight  Plan  Operation  Support  calls  Strip/Handoff  Processing  to 
process  the  acceptance.  Figure  49  on  page  149  shows  the  data  flows  used  and  generated  by  Flight  Plan 
Operation  Support. 
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7.0  FLIGHT  PLAN  OPERATIONS  SUPPORT  INTERFACES 


8.0  CONTROL  AREA 


EXPAND 

ROUTE 


UPDATE 
FIX  DATA 


7.3  STRIP/HANDOFF 
PROCESSING 


Figure  49.  Flight  Plan  Operation  Support  Interfaces.  This  figure  shows  the  interfaces  with  the  Flight  Plan  Operation" 
Support  functional  object,  and  the  other  functional  objects  of  the  DoD  AAS  ATC  Model. 


7.0  Inputs 
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•  VALIDATED_FLIGHT_PLANS  -  Flight  Plans  sent  from  FP  ENTRY  SUPPORT  to  FP  OPERA¬ 
TION  SUPPORT.  Flight  plans  have  been  syntax  and  geographically  checked.  They  require  route  proc¬ 
essing. 

•  CONTROLLER.ACK  HANDOFF-OUT  -  AREA  CONTROL  notifies  FLIGHT  PLAN  OPERA¬ 
TION  it  acknowledges  the  handoff.  FLIGHT  PLAN  OPERATION  SUPPORT  notifies  FLIGHT 
PLAN  STRIP/HANDOFF  PROC  that  the  controller  acknowledged  the  handoff-out. 

7.0  Outputs 

•  FP_WITHOUT_ROUTE_DATA  -  Flight  Plan  passed  from  FP  OPERATION  to  EXPAND  ROUTE  . 
for  the  purpose  of  completing  the  fixes  in  the  route. 

•  FP„WITH_TIME_UPDATES  -  Flight  Plan  which  has  had  a  time  modified  and  requires  a  new  trajec¬ 
tory  and  fix  metering  calculations. 

•  HANDOFF-OUT_INIT_REQUIRED  -  Indication  from  FP  OPERATION  SUPPORT  to 
STRIP/HANDOFF  PROC  that  it  is  time  to  initiate  a  handoff-out. 

•  STRIP_REQUIRED  -  Indication  from  FP  OPERATION  SUPPORT  to  STRIP/HANDOFF  PROC¬ 
ESSING  that  a  strip  is  required. 

•  CONTROLLER  ACK  HANDOFF-OUT  -  AREA  CONTROL  notifies  FLIGHT  PLAN  OPERA¬ 
TION  it  acknowledges  the  handoff.  FLIGHT  PLAN  OPERATION  SUPPORT  notifies  FLIGHT 
PLAN  STRIP/HANDOFF  PROC  that  the  controller  acknowledged  the  handoff-out. 
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7.0  Flight  Plan  Operation  Support  Functional  Object  Tree 

The  functional  object  tree  identifies  the  communication  paths  between  the  functional  objects  in  the  Flight 
Plan  Operation  Support  process.  Figure  50  on  page  152  shows  the  Functional  Object  Tree. 
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7.0  FLIGHT  PLAN  OPERATIONS  SUPPORT  FUNCTIONAL  OBJECT  TREE 


Figure  50.  7.0  Flight  Plan  Operation  Support  Functional  Object  Tree.  This  figure  illustrates  the  functional  object  tree 
for  the  Flight  Plan  Operation  Support  Functional  Object. 
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7.0  Flight  Plan  Operation  Support  Discussion 

When  Flight  Plan  Operation  Support  receives  validated  flight  plans  from  Flight  Plan  Entry  Support, 

Expand  Route  is  called  to  expand  the  route  data  in  the  flight  plan.  If  errors  in  the  route  are  detected,  they 
are  sent  to  the  controller.  If  no  errors  are  found,  Update  Fix  Data  is  called  to  create  a  trajectory  and  gen¬ 
erate  the  estimated  time  of  arrival  for  meterable  fixes. 

Flight  Plan  Operations  Support  also  scans  the  Active  Flight  Plan  Database  periodically  to  determine  any 
processing  that  is  required.  If  a  strip  is  required,  Flight  Plan  Operation  Support  calls  Strip/Handoff  Proc¬ 
essing  to  create  the  strip  and  send  it  to  the  appropriate  controller.  If  a  flight  plan  is  within  an  adapted  time 
from  crossing  a  sector  or  center  boundary,  Strip/Handoff  Processing  is  called  to  initiate  the  handoff.  When 
the  controller  acknowledges  the  handoff,  Flight  Plan  Operation  Support  calls  Strip/Handoff  Processing  to 
process  the  acceptance.  Figure  51  on  page  154  presents  the  processing  controlled  by  Flight  Plan  Operation 
Support. 
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7.1  Expand  Route 


7.1  Description 

Expand  Route  will  generate  all  fixes  along  the  route  specified  in  the  flight  plan  for  this  center.  If  there  are 
errors,  they  are  passed  on  to  the  controller.  If  no  errors  are  found,  the  expanded  flight  plan  is  passed  to 
Update  Fix  Data  for  further  processing. 

7.1  Inputs 

•  FP_WITHOUT_ROUTE_DATA  -  Flight  Plan  passed  from  FP  OPERATION  to  EXPAND  ROUTE 
for  the  purpose  of  completing  the  fixes  in  the  route. 

7.1  Outputs 

•  ROUTE_ERRORS  -  Errors  in  the  route  of  a  flight  plan.  Detected  by  EXPAND  ROUTE.  Sent  to  the 
originator  of  the  flight  plan. 

•  FP_WITH_ROUTE_DATA  -  Flight  plan  sent  from  EXPAND  ROUTE  to  UPDATE  FIX  DATA. 
Contains  expanded  route. 


7.2  Update  Fix  Data 

7.2  Description 


Update  Fix  Data  will  receive  the  flight  plan  data  from  Expand  Route  and  Flight  Plan  Operation  Support. 
Create  Trajectory  and  Generate  Meterable  Fix  Times  are  called  to  create  the  trajectory  and  generate  the  esti¬ 
mated  time  of  arrival  for  meterable  fixes.  If  the  flight  is  active,  the  Meterable  Fix  Counts  Database  is 
updated  with  the  meterable  fix  data.  If  conflict  situation  data  is  received  from  Prediction  and  Resolution,  the 
data  is  stored  in  the  appropriate  database. 


2  Inputs 

FP_WITH_TIME_UPDATES  -  Flight  Plan  which  has  had  a  time  modified  and  requires  a  new  trajec¬ 
tory  and  fix  metering  calculations. 

FP_WITH_ROUTE_DATA  -  Flight  plan  sent  from  EXPAND  ROUTE  to  UPDATE  FIX  DATA. 
Contains  expanded  route. 


CONFLICT_SITUATIONS  -  Conflict  data  sent  from  PREDICTION  &  RESOLUTION  to  UPDATE 
FIX  DATA  to  be  stored  in  the  appropriate  FP  database. 

FP_WITH_TRAJECTORY_DATA  -  FP  sent  from  CREATE  TRAJECTORY  to  UPDATE  FIX 
DATA  after  the  trajectory  data  has  been  provided. 


F  P_M  ETE  R I N  G_D  AT  A  -  Metering  data  for  the  FP,  sent  from  GENERATE  METERABLE  FIX 
TIMES  to  UPDATE  FIX  DATA  so  it  can  pass  the  data  to  the  appropriate  place. 


CONFLICT_DATA  -  Conflict  data  stored  in  the  ACTIVE  FP  database  by  UPDATE_FIX_DATA. 

FLIGHT_PLAN_CHANGES  -  Flight  Plan  with  changes,  sent  from  UPDATE  FIX  DATA  to  PRE¬ 
DICTION  AND  RESOLUTION  for  analysis  of  the  changes. 

FP_WITHOUT_TRAJECTORY_DATA  -  FP  sent  from  UPDATE  FIX  DATA  to  CREATE  TRA¬ 
JECTORY  for  the  purpose  of  filling  in  the  trajectory  data. 
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•  FP_NEEDING_METERING  -  FP  sent  from  UPDATE  FIX  DATA  to  GENERATE  METERABLE 
TIMES  for  the  purpose  of  calculating  metering  for  its  fixes. 


7.3  Strip/Handoff  Processing 

7.3  Description 

If  a  request  for  a  strip  is  received  by  STRIP/HANDOFF  PROCESSING,  the  strip  data  is  generated  and 
sent  to  the  appropriate  controller.  If  a  handoff-out  is  required,  Initiate  Handoff-Out  is  called  to  generate  the 
data  to  be  sent  to  the  controller  or  the  down-route  center  for  the  handoff.  When  the  controller  acknowl¬ 
edges  the  handoff,  Handoff-Out  Processing  is  called  to  update  the  appropriate  databases. 

7.3  Inputs 

•  HANDOFF-OUT_INIT_REQUIRED  -  Indication  from  FP  OPERATION  SUPPORT  to 
STRIP/HANDOFF  PROC  that  it  is  time  to  initiate  a  handoff-out. 

•  STRIP_REQ UIRED  -  Indication  from  FP  OPERATION  SUPPORT  to  STRIP/HANDOFF  PROC¬ 
ESSING  that  a  strip  is  required. 

•  CONTROLLER  ACK  HANDOFF-OUT  -  AREA  CONTROL  notifies  FLIGHT  PLAN  OPERA¬ 
TION  it  acknowledges  the  handoff.  FLIGHT  PLAN  OPERATION  SUPPORT  notifies  FLIGHT 
PLAN  STRIP/HANDOFF  PROC  that  the  controller  acknowledged  the  handoff-out. 

•  HANDOFF-OUT_INITIATED_DATA  -  Data  from  INITIATE  HANDOFF-OUT  to 
STRIP/HANDOFF  PROC  to  be  sent  to  the  controller. 

•  STRIP_DATA  -  Strip  data  sent  from  GENERATE  STRIP  to  STRIP/HANDOFF  PROC  for  distrib¬ 
ution  to  the  appropriate  controller/area. 

7.3  Outputs 

•  HANDOFF-OUT_NEEDED  -STRIP/HANDOFF  PROC  initiates  INITIATE  HANDOFF  with  this 
indication  that  a  handoff-out  is  needed. 

•  STRIP.NEEDED  -  Indication  from  STRIP/HANDOFF  PROC  to  GENERATE  STRIP  that  a  strip  is 
needed. 

•  CONTROLLER_HANDOFF-OUT_ACK  -  Acknowledgement  sent  from  STRIP/HANDOFF  PROC 
to  HANDOFF-OUT  PROC  to  indicate  the  controller  acknowledged  a  handoff-out. 

•  FLIGHT_PLAN_STRIPS_HANDOFF-OUT  -  Strips  containing  Flight  Plan  data.  Sent  from 
STRIP/HANDOFF  PROC  to  AREA  CONTROLLER  at  an  adapted  time  prior  to  flight  arrival  in  that 
area/sector. 
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7.2  Update  Fix  Data  Discussion 

When  Update  Fix  Data  receives  the  flight  plan  data  from  Expand  Route  or  Flight  Plan  Operation  Support, 
it  calls  Create  Trajectory  to  create  the  trajectory  for  the  flight.  Create  Trajectory  uses  the  current  weather 
data  along  with  the  aircraft  characteristics  to  create  the  trajectory.  Update  Fix  Data  also  calls  Generate 
Meterable  Fix  Times  to  generate  the  estimated  time  of  arrival  at  the  meterable  fixes  in  the  route.  Figure  52 
on  page  158  presents  the  processing  controlled  by  Update  Fix  Data. 
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Figure  52.  7.2  Update  Fix  Data  DFD.  This  figure  is  the  data  flow  diagram  for  the  IOiVI  Object,  7.2  Update  Fix 
Data 
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7.2.1  Create  Trajectory 

7.2.1  Description 

Create  Trajectory  receives  the  flight  plan  from  Update  Fix  Data.  It  creates  the  trajectory  for  the  flight  data 
and  returns  the  flight  plan  to  Update  Fix  Data. 

7.2.1  Inputs 

•  FP_WITHOUT_TRAJECTORY_DATA  -  FP  sent  from  UPDATE  FIX  DATA  to  CREATE  TRA¬ 
JECTORY  for  the  purpose  of  filling  in  the  trajectory  data. 

•  WEATHER_SURV_INFO  -  Weather  data  sent  from  WEATHER  SURVEILLANCE  to  CREATE 
TRAJECTORY.  Used  with  Aircraft  Characteristics  and  fixes  to  determine  trajectory. 

7.2.1  Outputs 

•  FP_WITH_TRAJECTORY_DATA  -  FP  sent  from  CREATE  TRAJECTORY  to  UPDATE  FIX 
DATA  after  the  trajectory  data  has  been  provided. 

7.2.2  Generate  Meterable  Fix  Times 

7.2.2  Description 

Generate  Meterable  Fix  Times  receives  the  flight  plan  with  trajectory  data.  A  list  containing  an  estimated 
time  of  arrival  for  each  meterable  fix  is  created  and  returned  to  Update  Fix  Data. 

7.2.2  Inputs 

•  FP_NEEDING_METERING  -  FP  sent  from  UPDATE  FIX  DATA  to  GENERATE  METERABLE 
TIMES  for  the  purpose  of  calculating  metering  for  its  fixes. 

7.2.2  Outputs 

•  FP_METERING_DATA  -  Metering  data  for  the  FP,  sent  from  GENERATE  METERABLE  FIX 
TIMES  to  UPDATE  FIX  DATA  so  it  can  pass  the  data  to  the  appropriate  place. 
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7.3  Strip/Handoff  Processing  Discussion 

When  a  request  for  a  strip  is  received  by  Strip/Handoff  Processing,  Generate  Strip  is  called  to  generate  the 
strip  data.  When  Strip/Handoff  Processing  receives  notification  that  a  handoff  is  required,  Initiate 
Handoff-Out  is  called  to  generate  the  data  to  be  sent  to  the  controller  or  the  down-route  center  for  the 
handoff.  When  the  controller  When  Strip/Handoff  Processing  is  notified  that  the  controller  acknowledged 
the  handoff,  Handoff-Out  Processing  is  called  to  update  the  appropriate  databases.  Figure  53  on  page  161 
presents  the  processing  controlled  by  Strip/Handoff  Processing. 
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Figure  53.  7.3  Strip/HandofF  Processing  DFD.  This  figure  is  the  DFD  for  the  IOM  Object,  7.3  Strip.Hando(f  Proc¬ 
essing. 
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7.3.1  Initiate  Handoff-Out  Processing  Discussion 

7.3.1  Description 

Initiate  Handoff-Out  Processing  Receives  a  request  to  initiate  a  handoff  from  STRIP/HANDOFF  Proc¬ 
essing.  Data  for  the  controller  is  generated  and  sent  to  Strip/Handoff  Processing  to  be  sent  to  the  appro¬ 
priate  controller.  Generate  Strip  is  called  to  generate  the  strip  for  the  next  controller. 

7.3.1  Inputs 

•  HANDOFF-OUT_NEEDED  -STRIP/HANDOFF  PROC  initiates  INITIATE  HANDOFF  with  this 
indication  that  a  handoff-out  is  needed. 

7.3.1  Outputs 

•  HANDOFF-OUT_INITIATED_DATA  -  Data  from  INITIATE  HANDOFF-OUT  to 
STRIP/HANDOFF  PROC  to  be  sent  to  the  controller. 

7.3.2  Generate  Strip  Discussion 

7.3.2  Description 

Generate  Strip  generates  a  strip  for  the  flight  plan.  The  strip  is  sent  to  Strip/Handoff  Processing  to  be  sent 
to  the  appropriate  controller. 

7.3.2  inputs 

•  STRIP_NEEDED  -  Indication  from  STRIP/HANDOFF  PROC  to  GENERATE  STRIP  that  a  strip  is 
needed. 

7.3.2  Outputs 

•  STRIP_DATA  -  Strip  data  sent  from  GENERATE  STRIP  to  STRIP/HANDOFF  PROC  for  distrib¬ 
ution  to  the  appropriate  controller/area. 

7.3.3  Handoff-Out  Processing 

7.3.3  Description 

Handoff-Out  Processing  receives  the  flight  plan  for  which  a  handoff  was  acknowledged  from  Strip/Handoff 
Processing.  If  the  flight  plan  was  handed-off  to  a  down-route  center,  it  is  deleted  from  the  Active  Flight 
Plan  Database. 

7.3.3  Inputs 

•  CONTROLLER_HANDOFF-OUT_ACK  -  Acknowledgement  sent  from  STRIP/HANDOFF  PROC 
to  HANDOFF-OUT  PROC  to  indicate  the  controller  acknowledged  a  handoff-out. 

7.3.3  Outputs 

•  DELETE_HANDOFF-OUT_FP  -  Delete  the  FP  that  was  handoff-out  processed  from  the  ACTIVE 
FP  database  for  this  area. 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  7.0  Flight 
Plan  Operations  Support. 

Flight  Plan  Operation  Support  Information  Flows 

The  following  report  identifies  the  inputs  to  and  outputs  from  each  of  the  functional  objects  in  the  Flight 
Plan  Entry  Support  process. 
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R  ROUTE  DATA 
E  REMARKS 


I  I 

i  ■ 

>  l 

:  i 

!  I 

!  *  I 

!  I 

i  i 


ISF  FP.fE7EGIN6.DAM 
!  REC  FLIGHT  PLAN  NETESI.V3  DATA 

.  E  FIX 

I  E  ESTIMATED  TINE  Or  ARRIVAL 


I 

I 

I 
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POCEsS:  7.3.1 


LABEL:  INITIATE  HANDOFF-  OUT 


OF  HANDGFF-QUT  NEEDED  I 

!  SEC  HANDQFF-QUT. NEEDED  I 

i  E  FLIGHT  FLAN  ID . I . t 

‘  E  FLIGHT.LOCATIGN . i . » 

I  IDF  HAIiDOFF-OJT  INITIATED  DATA 

i  I  REC  HAN50FF-GUT  INITIATED  DATA 

I  ♦ . i  .  .  .£  FLIGHT.FLAN.ID 

!  * . i  .  .  ,E  FLIGHT  LCDATIGN 


Naans  Updated  Data 


*»•»  lies u £  Updatsd  Ddtd 


DATE:  li 


PROCESS: 


I  OF 
I 
i 
I 


-JAN-90 

\ki 

HE:  7.3  STRZP/HANC3FF  PR3C 
7.3.3 

INPUT 

CCNTROLLER.HANOGFF-OJUCK 
EL£  FLIOHT.PLAH.ID.  .  .  . 
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Since  Flight  Plan  Operation  Support  is  closely  tied  Flight  Plan  Entry  Support,  refer  to  the  Information 
Flows  described  in  the  Section  Supplement  for  Flight  Plan  Entry  Support. 
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8.0  Area  Control 


This  section  is  not  formally  documented.  This  entry  was  included,  for  coverage  completeness,  from  available 
materials. 

Introduction 

The  AREA  CONTROL  encapsulates  the  functions  of  the  Enroute  and  Approach  Control  Facilities.  It  pro 
vides  Area  Flow  Control,  which  interfaces  with  the  National  Flow  Controller,  for  the  effective  and  safe  utili¬ 
zation  of  airspace  and  managing  airspace  congestion. 

The  AREA  CONTROL  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Area  Control  View  From 

•  The  Area  Control  Interfaces 

•  The  Area  Control  Functional  Object  Tree 

•  Area  Control. 

8.0  Area  Control  "View  From" 

The  DoD  AAS  Area  Control  view  from  8.0  AREA  CONTROL  is  illustrated  by  Figure  54  on  page  166. 
The  'view  from'  presents  all  of  the  major  functional  objects  of  the  DoD  AAS  Area  Control  and  their 
relationship  to  AREA  CONTROL  by  the  messages  that  are  passed  to  and  from  it. 


8.0  Area  Control  164 


STARS  Deliverable  1200 


Figure  54.  DoD  AAS  Area  Control  View  from  Area  Control.  This  figure  illustrates  the  view  of  DoD  AAS  Area 

Control  with  respect  to  AREA  CONTROL.  This  diagram  also  presents  all  of  the  major  functional  objects 
of  the  DoD  AAS  Area  Control  IOM  and  the  message  'pipes'  that  connect  them  to  AREA  CONTROL. 
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8.0  Area  Control  Interfaces 

The  interfaces  to  AREA  CONTROL  are  illustrated  on  Figure  55  on  page  168. 
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8.0  AREA  CONTROL  INTERFACES 


6.0 

FLIGHT 
PUN  ENTRY 
SUPPORT 
7.0 

FLIGHT  PUN 
OPERATIONS 
SUPPORT 

2.0 

WEATHER 
SURVEILUNCE 


3.0 

PREDICTION  & 
RESOLUTION 


FPS/AMENDS/ 
UPDATES/ 
TRIAL  FPS/ 
ERROR  MSGS 


WEATHER 
SURV  DISP 
DATA 


FUGHT  PUN 
STRIPS/ 
HANDOFFS-OUTl 


S.0 

AIRCRAFT  & 
TRACK 

MANAGEMENT 


1.0 

TRAFFIC  - 

SURVEILUNCE  4.0 

RECORDING 

SUPPORT 
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APPROACH 
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Figure  55.  Interfaces  for  8.0  AREA  CONTROL.  This  figure  illustrates  the  interfaces  of  the  the  8.0  Area  Control 
functional  object.  This  diagram  shows  the  major  inputs  from  other  DoD  AAS  Area  Control  functional 
objects  and  external  interfaces. 
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8.0  Area  Control  Inputs 
Not  available.  , 

8.0  Area  Control  Outputs 
Not  available. 

1.0  Area  Control  Functional  Object  Tree 

The  functional  object  tree  for  1.0  AREA  CONTROL  presents  the  object  hierarchy  of  AREA  CONTROL, 
as  illustrated  in  Figure  56  on  page  170  The  functional  object  tree  presents  all  of  the  graphics  used  to 
describe  AREA  CONTROL,  as  well  as  the  message  communication  paths  that  show  communication 
between  peer  objects,  parent  objects  to  child  objects,  and  child  to  parent  objects. 
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8.0  AREA  CONTROL  FUNCTIONAL  OBJECT  TREE 


Figure  56.  Functional  Object  Tree  for  1.0  Area  Control.  This  figure  illustrates  the  functional  object  tree  for  the 

AREA  CONTROL  functional  object.  This  tree  shows  the  hierarchic  relationship  between  the  subordinate 
functional  objects  and  shows  message  passing  between  peer  objects,  parent  objects  and  child  objects  on 
different  levels;  It  also  identifies  the  communication  paths  between  the  decomposition  levels. 
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Area  Control  Discussion 

The  figure  illustrating  Area  Control  is  presented  in  Figure  57  on  page  172  This  figure  illustrates  the  infor¬ 
mation  flow  from  other  system  objects  and  the  information  flow  between  the  Enroute  Controller  and  the 
Approach  Controller  objects. 
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Figure  57.  8.0  Area  Control.  This  figure  illustrates  the  first  level  of  decomposition  of  AREA  CONTROL  functional 
object,  and  illustrates  the  information  flow  between  Enroute  Controller  and  Approach  Controller  objects. 
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8.1  Enroute  Controller 

The  human  component  of  the  Enroute  controller  is  described  below. 

•  Generally  has  a  very  large  airspace  to  monitor  and  control; 

•  Uses  information  from  the  integrated  information  view  and  external  sources  to  guide  and  control  aircraft 
in  a  safe  fashion; 

•  Updates  system  time  according  to  WWV; 

•  Monitors  weather  reports  from  pilots  and  national  weather  agencies  in  order  to  enter  the  information  in 
to  the  computer  system; 

•  Answers  many  different  kinds  of  pilot  questions; 

•  Receives  traffic  advisories  from  Area  Control; 

•  Controls  the  way  in  which  data  is  presented  on  the  computer  screen; 

•  Receives/performs  handoffs  from/to  other  Enroute  controllers  as  well  as  Approach  Controllers. 


8.2  Approach  Controller 

The  human  component  of  the  Approach  Controller  is  described  below. 

•  Airspace  is  limited  to  a  short  range  around  the  airport; 

•  Does  much  the  same  thing  as  the  Enroute  Controller; 

•  Receives/performs  handoffs  from/to  Enroute  controllers  and  Tower  controllers. 
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8.1  Enroute  Controller  Discussion 

The  figure  illustrating  the  decomposition  of  the  Enroute  Controller  is  illustrated  in  Figuie  58  on  page  175. 
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Figure  58.  8.1  Enroute  Controller.  This  figure  illustrates  the  first  level  of  decomposition  of  Enroute  Controller  func¬ 
tional  object,  showing  the  Enroute  Display  Dialog  Manager  object. 
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8.1.1  Enroute  Display  Dialog  Manager 

•  Receives  information  from  all  of  the  other  objects  and  some  outside  sources,  formats  it  to  the  controllers 
liking,  and  displays  it  on  the  screen; 

•  Accepts  controller  commands  and  requests  for  information.  These  commands  are  then  passed  on  to  the 
appropriate  functions; 

•  Logs  screen  images  for  future  playback; 

•  Logs  all  controller  requests  and  commands; 

•  Performs  pointout  functions. 
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8.2  Approach  Controller  Discussion 

The  figure  illustrating  the  decomposition  of  the  Approach  Controller  is  illustrated  in  Figure  59  on  page  178. 
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Figure  59.  8.2  Approach  Controller.  This  figure  illustrates  the  first  level  of  decomposition  of  Approach  Controller 
functional  object,  showing  the  Approach  Display  Dialog  Manager  object. 


8.0  Area  Control  177 


STARS  Deliverable  1200 


8.2.1  Approach  Display  Dialog  Manager 

•  Receives  information  from  all  of  the  other  objects  and  some  outside  sources,  formats  it  to  the  controllers 
lilting,  and  displays  it  on  the  screen; 

•  Accepts  controller  commands  and  requests  for  information.  These  commands  are  then  passed  on  to  the 
appropriate  functions; 

•  Logs  screen  images  for  future  playback; 

•  Logs  all  controller  requests  and  commands; 

•  Performs  Pointout  functions. 
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8.0  Tower  Control  Discussion 

8.1  Ground  Controller 

•  Responsible  for  all  the  safe  movement  of  all  ground. 

•  Controls  aircraft  while  traveling  from  gate  to  runway,  traffic. 

•  Issues  handoff  to  Tower  Controller. 

8.2  Tower  Controller 

•  Responsible  for  the  safe  takeoff  and  landing  of  all  aircraft. 

8.3  Clearance  Controller 

•  Obtains  all  necessary  clearances  for  an  aircraft  to  takeoff. 

•  Issues  handoff  to  Ground  Control. 
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Section  Supplement 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  8.0  Area 
Control. 

"Ail  Data  Flows'  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  flows  for  the  Area  Control 
object. 
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DATE:  26-APR-90 
TIKE:  19:5? 


h*  ALL  DATA  FLOWS  FOR  AREA  CONTROL  *« 


PAGE  1 
EXCEL/STS 


Naae 

Alternate  Naas  ' 

Short  Descrip. 

Last  Modify  Cate 

SCF19 

AC  AND  ENVIRONMENT  DATA 

Record  containinq  ouch  of  the  data  stored  in  AAS. 

891216 

SEF19 

AIRPORT  AND  AP  ASSET  STATUS 

Contains  aosi  of  the  intonation  that  defines  an  airport 
and  the  equipaent  it  has. 

891216 

SCF15 

APPROACH  CONTROLLER  COMMANDS 

Ccaiands  and  requests  froa  the  approach  controller  to  the 
operational  air  traffic  control  systec. 

391216 

SCF16 

APPROACH  CONTROL-.ER  LOG  DATA 

Coaiands  and  requests  aade  by  the  approach  controller  which 
are  to  be  loqqed. 

891216 

SCF17 

APPROACH  DISPLAY  LOG  DATA 

Contains  intonation  necessary  to  recreate  the  iaaqe  a 
qiven  controller  sees  at  a  qiven  tiae, 

891216 

SCF1A 

AREA  CONTROL  LOB  DATA 

Data  that  needs  to  be  loqqed  as  a  result  of  controller 
actions  or  iaaqes  displayed  to  controller. 

391216 

3CF0S 

AREA  TOWER  COMMUNICATIONS 

Coaiunications  that  nust  qc  froa  the  area  controllers  to 
the  tower  controllers  (include  handoffs,  requests,  etc.! 

891216 

SEF07 

CONTROLLER  PILOT  COMMUNICATIONS 

Coaaunication  froa  a  controller  to  a  pilot  and  froa  a  pilot 
back  to  a  controller. 

891216 

SCFIO 

ENRGUTE  CONTROLLER  COMMANDS 

Coaaands  ar.d  requests  froa  the  enreute  controller  to  the 
operational  air  traffic  control  systea. 

S91216 

3CF00 

ENROUTE  CONTROLLER  LOG  DATA 

Consists  of  all  keystrokes  the  controller  aakes.  This 
includes  cueries,  coaaands  and  view  preferences. 

391213 

SCFII 

ENROUTE  DISPLAY  LOG  DATA 

Data  necessary  to  recreate  the  screen  iaaqes  of  a  qiven 
controller  at  a  qiven  tine. 

291216 

3CFSO 

INTEGRATED  INFORMATION  VIEW 

The  screen  naqe  containinq  situation  inforaation  and  other 
controller  requested  inforaation. 

391216 

ECF06 

NATIONAL  STANDARD  TINE 

The  national  standard  tiae  used  to  synchronize  ail  air 
traffic  control  facilities. 

2912io 

SCF<?2 

SITUATION  DATA  ANE  HAHDCFFS 

Inforaation  that  needs  to  be  passed  between  approach 
controllers  and  enreute  controllers. 

59121s 

SCFO-* 

7RAFciC  DENSITY 

A  reoort  ^ros  the  enroute  controller  containinq  information 
aoout  the  aaount  of  traffic  in  a  civen  area. 

391216 

3CF01 

VIEW  F REFERENCES 

Cof. sands  froa  the  controller,  tel'.ino  PRESENTATION  SERVICES 
tne  aanner  in  which  to  rorsat  the  cispiay  !e.c,  ccicrs;. 

39121! 

5CF'-3 

WEATHER  REPOSTS 

Weatner  reports  -"rss  national  weather  sources  such  as  ACCli 
weather. 

39:216 
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'All  Records  and  their  Elements'  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  the  records  and  their  elements 
for  the  Area  Control  object. 
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*»  ALL  RECORDS  FOR  AREA  CONTROL  «* 


i 


PAGE 
EXCEL/RTS 


Naae 

=f  ELE/REC  Nase 

H  Definition 

( 

SC  AND  ENVIRONMENT  DATA 

=(  AIRSPACE  BOUNDARIES 
*•  GROUND  OBSTACLES 
t  GEOGRAPHIC  DATA 
+  RULES  AND  REGULATIONS 
+  AIRCRAFT  CHARACTERISTICS 
*  ESTABLISHED  ROUTES 
+  NAVABATION  AID  FIXES 

) 

AIRCRAFT  CHARACTERISTICS 

=<  AC  TYPE 
+  MAX  VELOCITY 
+  MIN  VELOCITY 
♦  MAX  ALTITUDE 
+  AC  HEIGHT 

Contains  information  asout  specific  kinds  of  A/C 

) 

AIRSPACE  BOUNDARIES 

=(  AIRSPACE  ID 
+  COORDINATE  LIST 

Describes  a  given  area  on  :hs  airspace  being  controlled. 

\ 

A I SHAY  FIXES 

+!  FIX  MAP  DATA 
+  AIRWAY  DIRECTION  FIX  IND 
+  FIX  JUNCTIONS  DATA 
+  FIX  COORDINATION  DATA 
*  FIX  SEGMENT  DATA 
t  FIX  NAME 

Fix  specification  indorsation 

1 

i 

AIRWAY  ROUTE  DATA 

=(  AIRWAY  IDENTIFIER 
*  AIRWAY  FIXES 

Airway  route  data  ldentifyinq  all  mfc  about  .-cutes. 

) 

ALLOCATIONS  AND  ADVISORIES 

AREA  'ONER  COMMUNICATIONS 

CONTROLLER  PILOT  COMMUNICATIONS 

Suqqested  asount  of  traffic  through  certain  areas. 

Ccesunications  aetween  the  area  and  tower  controllers. 

•Cossunications  aetween  the  pilot  and  controller 

COORDINATE  LIST 

=!  X  COORDINATE 
+  Y  COORDINATE 
+  2  COORDINATE 

Seq.  of  points  in  s'/stes  coordinates  defmno  airspace 

) 

ESTABLISHED  ROUTES 

=(  PREF  ROUTES 
+  STEREO  ROUTES 

Classifications  of  airway  routes 

) 

-’ll  COORDINATION  DATA 

=1  FIX  COORDINATION  TYPE 

*  FIX  COORDINATION  DIRECTION 

♦  FIX  COORDINATION  ALTITUDES 

*  FIX  COORDINATION  CENTERS 

♦  FIX  COORDINATION  AREAS 

Dest.  for  coordination  FC'Es  aene'-ated  wren  prsearv  qener 

) 

FIX  DATA 

=1  FIX  NAME 

i-  FIX  LOCATION  DATA 

Inforcation  needeo  L-  locate  a  fix. 

! 

"X  JUNCTION!, !le  DATA 

=  t  FIX  JUNCTION!)!]  TV"E 
*  FIX  JUNCTIONS  NAME 

Identifies  all  routes  chat  intersect  at  specific  fix 

i 
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Nate  ‘  =(  ELE/REC  Na*e 

FIX  LOCATION  DATA  =(  AIRPORT  INDICATOR 

+  FIX  LATITUDE 
+  FIX  LONGITUDE 
+  FIX  MAGNETIC  DECLINATION 
+  FIX  HIND  STATION 
+  BOUNDARY  CROSSING  FIX  IND 
+  FIX  MAP  DATA 

FIX  MAP  DATA  *(  FIX  HAP  CLASS  TYPE 

+  FIX  MAP  DASH  VALUE 

♦  FIX  MAP  START  NUMBERS 
+  FIX  HAP  STOP  NUMBERS 

GEOGRAPHIC  DATA 

GROUND  OBSTACLES  »(  GROUND  OBSTACLE  NAME 

♦  GROUND  OBSTACLE  ID 
+  COORDINATE  LIST 

IfAVAGATION  AID  FIXES  =(  AIRWAY  FIXES 

RULES  AND  REGULATIONS  =(  RULE  IDENTIFICATION 

♦  RULE  DESCRIPTION 

5EPEF.ATI0N  CRITERIA  =1  AIRCRAFT  PAIS  TYPE 

*  PREFERRED  HORIZ  OPERATION 

,  ♦  PREFERRED  VERT  SERRATION 

'  *  SECONDARY  HORIZ  SEPERATION 

r  SECONDARY  VERT  SEPERATICN 

SID  DATA  =(  SID  IDENTIFIER 

t  ROUTE  NAME  4  AIRCRAFT  CLASS 

♦  SID  ELISI3LE  ALTITUDES 

♦  SID  ROUTE  FIXES 

i  SiD  STAR  ACTIVE  INACTIVE  ID 

SID  ROUTE  FIXES  *(  DEPARTURE  AIRPORT  IND 

*  AUTOMATIC  TRACK  INIT  IND 
r  AUTO  HANOOFF  POINT  ALT 

f  TRANSITION  FIX  IND 
t  FIX  COORDINATION  DATA 

*  FIX  HAP  DATA 
r  FIX  NAME 

f  AUT0  INTERIM  ALTITUDE  DATA 

=(  STEREO  TAG  NAME 

*  STEREO  AIRCRAFT  SATA 
i  STEREO  SPEED 

*  FIX  COORDINATION  DATA 
+  STEREO  ALTITUDE 
t  STEREO  REMARKS 


)f  Definition 

Location  record  for  fixes 

) 

Inforaation  about  the  jap  line  beoun  or  ended  at  fix 

) 

List  of  Ground  obstacles  needinq  to  be  avoided  by  AC, 

) 

)  Fixes  used  to  aid  in  navigation 

Defines  the  rules  and  regulations  required  by  facilities. 

) 

Criteria  used  by  conflict  orobe  to  ascertain  r.m  sep, 

) 

Standard  Ir.strucent  Deoarture  data  record 

> 

List  of  fixes  alonq  the  route 
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DATE:  26-APR-SO 

m  ALL  ELEMENTS  FOR  AREA  CONTROL  ***  PA3E  I 

TIME:  EO:Oi 

A 

EXCEL/RTS 

W' 

■'  Naae 

=(  ELE/SEC  Naie 

)+  Definition 

AC  AND  ENVIRONMENT  DATA 

=(  AIRSPACE  BOUNDARIES 
+  GROUND  OBSTACLES 
+  GEOGRAPHIC  DATA 
+  RULES  AND  REGULATIONS 
+  AIRCRAFT  CHARACTERISTICS 
+  ESTABLISHED  ROUTES 
♦  NAVASATIGN  AID  FITES 

) 

AIRCRAFT  CHARACTERISTICS 

=(  AC  TYPE 
t  MAX  VELOCITY 
+  MIN  VELOCITY 
t  MAX  ALTITUDE 
*  AC  HEIGHT 

Contains  information  about  specific  kinds  of  A/C 

! 

AIRSPACE  BOUNDARIES 

=(  AIRSPACE  ID 
f  COORDINATE  LIST 

Describes  a  qiven  area  on  the  airspace  beinq  controlled. 

) 

AIRWAY  FITES 

*(  FIX  MAP  DATA 
+  AIRWAY  DIRECTION  FIX  IND 
t  FIX  JUNCTIGNINS  DATA 
+  FIX  COORDINATION  DATA 

Fix  specification  information 

• 

+  FIX  SEGMENT  OATA 
*  FIX  NAME 

) 

AIRWAY  ROUTE  DATA 

=(  AIRWAY  IDENTIFIER 
+  AIRWAY  FIXES 

Airway  route  data  icentifyinq  all  info  about  routes. 

) 

ALLOCATIONS  AND  ADVISORIES 

Suqqested  asount  of  traffic  thrcuqii  certain  aress. 

AREA  TCUEit  CGMPL'NICATICiS 

Cosnunications  between  the  area  and  tower  controllers. 

CONTROLLER  PILOT  COMMUNICATIONS 

Coosunications  between  the  pilot  and  controller 

COORDINATE  LIST 

=(  X  COORDINATE 
+  Y  COORDINATE 
*  Z  COORDINATE 

Seq.  of  points  in  systee  coordinates  defining  airspace 

) 

ESTABLISHED  ROUTES 

=i  PREF  ROUTES 
*  STEREO  ROUTES 

Classifications  of  airway  routes 

"A  COORDINATION  DATA 

=(  FIX  COORDINATION  TYPE 

♦  FIX  COORDINATION  DIRECTION 
r  FIX  COORDINATION  ALTITUDES 

♦  FIX  COORDINATION  CENTERS 

♦  FIX  CGDRBINATICN  AREAS 

Dest.  for  coordination  FDEs  qenerated  wnen  crisary  qener. 

i 

Fit  DA'A 

=C  FIX  NAME 

information  needed  to  locate  a  fix. 

+  FIX  LOCATION  DATA 

) 

I X  JL'OIGHING  DA'A 

■l  FIX  JL'NCTIQNING  FPE 

Identifies  ail  routes  that  intersect  at  specific  fit 

*  FIX  JUNCTIGNINS  NAME 

1 

DATE:  2S-APR-90 
TINE:  20:01 


t*t  ALL  ELEMENTS  FOR  AREA  CONTROL  w 


PAGE  2 
EXCEL/RTS 


Naee 

=(  ELE/REC  Name 

)+  Definition 

FIX  LOCATION  DATA 

=(  AIRPORT  INDICATOR 
+  FIX  LATITUDE 
+  FIX  LONGITUDE 
+  FIX  MAGNETIC  DECLINATION 
♦  FIX  KIND  STATION 
+  BOUNDARY  CROSSING  FIX  IND 
+  FIX  HAP  DATA 

Location  record  for  fixes 

! 

FIX  MAP  DATA 

*{  FIX  MAP  CLASS  TYPE 

*  FIX  MAP  DASH  VALUE 

*  FIX  MAP  START  NUMBERS 
+  FIX  HAP  STOP  NUMBERS 

Information  about  the  ctac  line  bsqun  or  ended  at  fix 

) 

GEOGRAPHIC  DATA 

GROUND  OBSTACLES 

=<  GROUND  OESTACLE  NAME 
+  6R0UND  OBSTACLE  ID 
♦  COORDINATE  LIST 

List  of  Ground  obstacles  needinq  to  be  avoided  by  AC. 

) 

NAVAGATIQN  AID  FIXES 

■(  AIRWAY  FIXES 

)  Fixes  used  to  aid  in  naviqaticn 

RULES  AND  REGULATIONS 

=(  RULE  IDENTIFICATION 
+  RULE  DESCRIPTION 

Defines  tne  rules  and  requhtions  required  cy  facilities. 

) 

SEPERATION  CRITERIA 

■(  AIRCRAFT  PAIR  TYPE 
+  PREFERRED  H0RI2  SERRATION 
+  PREFERRED  VERT  SEPERATION 
'  ♦  SECONDARY  HORIZ  SEPERATION 
+  SECONDARY  VERT  SEPERATION 

Criteria  used  by  conflict  probe  to  ascertain  air.  sap. 

) 

319  DATA 

=(  SID  IDENTIFIER 
+  ROUTE  NAME  L  AIRCRAFT  CLASS 
+  SID  ELIGIBLE  ALTITUDES 
+  SID  ROUTE  FIXES 
*  SID  STAR  ACTIVE  INACTIVE  ID 

Standard  instrument  Departure  data  record 

) 

SID  ROUTE  FIXES 

=1  DEPARTURE  AIRPORT  IND 

*  AUTOMATIC  TRACK  INIT  IND 

*  AUTO  HANDOFF  POINT  ALT 
t  TRANSITION  FIX  IND 

t  FIX  COORDINATION  DATA 

*  FIX  MAP  DATA 
t  FIX  NAME 

r  AUTO  INTERIM  ALTITUDE  DATA 

List  of  fixes  alonq  the  route 

J 

STEREO  ROUTE  DATA 

=(  STEREO  TAS  NAME 
t  STEREO  AIRCRAFT  DATA 
t  STEREO  SPEED 
+  FIX  COORDINATION  DATA 
+  STEREO  ALTITUDE 
+  STEREO  REMARKS 

Stereo  route  lr.fcrsation  tag. 
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'All  Data  Stores'  Report 

The  8.0  Area  Control  object  employs/updates  the  following  globally  defined  data  stores,  defined  in  Appendix 
A  of  this  document: 

•  AIRCRAFT_AND_ENVIRONMENT_DATA  (employs/updates) 

•  METERABLE_FIX_COUNTS  (employs) 

•  TRACKHISTORY  (employs) 

•  AIRPORT_AND_AP_ASSET_STATUS  (employs/updates) 

•  FLIGHT_PLANS  (employs). 
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4.0  Recording  Support 

This  section  is  not  formally  documented.  This  entry  was  included  for  coverage  completeness,  from  available 
materials. 

Introduction 

The  4.0  Recording  Support  object  is  responsible  for  managing  and  recording  required  log  data. 

The  RECORDING  SUPPORT  object  will  be  introduced  by  four  graphics,  namely: 

•  The  Recording  Support  View  From 

•  The  Recording  Support  Interfaces 

•  The  Recording  Support  Functional  Object  Tree 

•  Recording  Support. 

1.0  Recording  Support  "View  From" 

The  DoD  AAS  Area  Control  view  from  4.0  RECORDING  SUPPORT  is  illustrated  by  Figure  60  on 
page  185.  The  'view  from'  presents  all  of  the  major  functional  objects  of  the  DoD  AAS  Area  Control  and 
their  relationship  to  RECORDING  SUPPORT  by  the  messages  that  are  passed  to  and  from  it. 
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Figure  60.  DoD  AAS  Area  Control  View  from  Recording  Support.  This  figure  illustrates  the  view  of  DoD  AAS 
Area  Control  with  respect  to  RECORDING  SUPPORT.  This  diagram  also  presents  all  of  the  major 
functional  objects  of  the  DoD  AAS  Area  Control  IOM  and  the  message  'pipes'  that  connect  them  to 
RECORDING  SUPPORT. 
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4.0  Recording  Support  Interfaces 

The  interfaces  to  RECORDING  SUPPORT  are  illustrated  on  Figure  61  on  page  187. 
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4.0  RECORDING  SUPPORT  INTERFACES 


4,1  SOURCE  &  TIME 
TAGGING 


Figure  61.  Interfaces  for  4.0  RECORDING  SUPPORT.  This  figure  illustrates  the  interfaces  of  the  the  4.0 

Recording  Support  functional  object.  This  diagram  shows  the  major  inputs  from  other  DoD  AAS  Area 
Control  functional  objects  and  external  interfaces. 
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4.0  Recording  Support  Inputs 
Not  available.  ■ 

4.0  Recording  Support  Outputs 
Not  available. 

1.0  Recording  Support  Functional  Object  Tree 

The  functional  object  tree  for  1.0  RECORDING  SUPPORT  presents  the  object  hierarchy  of 
RECORDING  SUPPORT,  as  illustrated  in  Figure  62  on  page  189  The  functional  object  tree  presents  all 
of  the  graphics  used  to  describe  RECORDING  SUPPORT,  as  well  as  the  message  communication  paths 
that  show  communication  between  peer  objects,  parent  objects  to  child  objects,  and  child  to  parent  objects. 
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4.0  RECORDING  SUPPORT  FUNCTIONAL  OBJECT  TREE 


r  4.0  > 

RECORDING 


DIAGRAM  0.0 


-DIAGRAM  4.0 


f  4.1  > 

SOURCE  & 
TIME 

,  TAGGING  , 


/  4.2  > 

ORGANIZE  & 

V  CATALOG  J 


Figure  62.  Functional  Object  Tree  for  1.0  Recording  Support.  This  figure  illustrates  the  functional  object  tree  for  the 
RECORDING  SUPPORT  functional  object.  This  tree  shows  the  hierarchic  relationship  between  the  sub¬ 
ordinate  functional  objects  and  shows  message  passing  between  peer  objects,  parent  objects  and  child 
objects  on  different  levels;  It  also  identifies  the  communication  paths  between  the  decomposition  levels. 
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Recording  Support  Discussion 

Recording  support  is  the  process  required  for  the  logging  of  system  data,  which  includes: 

•  ATC  Traffic  Counts  -  number  of  IFR  aircraft,  controller  VFR  aircraft;  count  of  adapted  routes,  speed 
distribution,  altitude  distribution;  number  of  arrivals,  departures,  overflights,  and  withins  (within  sectors); 
number  of  flight  plans,  separation  incidents,  traffic  management 

•  Hardware  and  software  performance  information 

•  Data  to  determine  the  average  times  and  speeds  of  flights  within  sectors  and  sectors  traversed  per  flight. 
RECORDING  SUPPORT  is  presented  in  Figure  63  on  page  191. 
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Figure  63.  4.1  Recording  Data  DFD.  This  figure  is  the  information  flow  for  4.1  Recording  Data. 
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4.1  Source  and  Time  Tagging 

The  purpose  of  SOURCE  AND  TIME  TAGGING  is  to  Identify  the  source  and  time  of  the  log  data,  and 
output  a  tag  for  the  data. 

4.2  Organize  and  Catalog 

The  purpose  of  ORGANIZE  AND  CATALOG  log  data  is  to  sort  and  categorize  the  tagged  log  data  and 
write  the  data  to  the  air  traffic  control  log. 

Section  Summary 

This  section  provides  summary  reports  on  data  employed  and  derived  by  the  functional  object  4.0  Recording 
Support. 

"All  Data  Flows"  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  flows  for  the  Recording 
Support  object. 
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DATE: 

TIME: 

26-APP.-90 

20:47 

«*  ALL  DATA  FLOWS  -  HJC 

PAGE  1 

EXCEL/RTS 

Naae 

Alternate  Nase 

Short  Descrip. 

Last  Modify  Date 

0.14 

RULES  i  REGULATIONS 

Follows  the  rules  and  requlations  dictated  by  0.1  AC  and 

ENV  Data  as  to  what  data  should  be  loqqed. 

891213 

M000S 

STATUS/EVENTS  REPORTS 

Loq  data  requested  free  Airway  Facilities  for  the  creation 
of  status/events  reports.  Reports  created  by  Airway  Facil. 

391216 

, 10003 

TAGGED  DATA 

Data  sent  fro#  4.1  SGURCE  &  TIKE  TAGGING  to  4.2  CATALOG  i 
ORGANIZE  which  has  the  source  and  tiae  appended  to  it. 

891216 

M0004 

TfiSGEE/CATALQSED  DATA 

Data  that  has  been  source/tiae  taqqed  and  orqanized  and 
cataloqed,  and  is  sent  to  the  ATC  loq  for  storaqe. 

=91216 
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'All  Data  Stores'  Report 

The  following  report,  generated  from  the  Excelerator  database,  identifies  all  data  stores  for  the  Recording 
Support  Object.  4.0  Recording  Support  also  employs  the  following  globally  defined  data  store,  defined  in 
Appendix  A  of  this  document: 

•  AIRCRAFT_AND_ENVIRONMENT_DATA. 
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DATE:  26-APR-90 
TIME:  £0:56 


a*  ALL  DATA  STORES  -  «JC  *« 


PASE  ! 
EXCEL/RTS 


Nate  Alternate  Nate  -  Lonq  Description 


-.I  ATC  LOS  This  data  store  collects  the  analyzed  Icq  data,  and  records  it  at  a 

centralized  location  for  efficient  retrieval.  Airway  facilities  can 
then  retrieve  the  data  that  is  needed  for  creatinq  their  reports. 


Last.  Modify  Date 


391216 
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Appendix  A.  Appendix  A  -  Ail  DoD  AAS  Area  Control  Data 
Stores 
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OATH:  25-APR-90 

TIME:  15:35 

*«  ALL  DATA  STORES  *« 

PAGE  1 

EXCEL/STS 

Alternate  Naae 

Contains  Data  St 

Last  Modify  Date 

0.22 

ACTIVE  FLIGHT  PLANS 

891216 

0.1 

AC  AND  ENVIRONMENT  DATA 

RULES  AND  REGULATIONS 
AIRCRAFT  CHARACTERISTICS 
ESTABLISHED  ROUTES 
NAVIGATION  AID  FIXES 
AIRSPACE  BOUNDARIES 

GROUND  OBSTACLES 
GEOGRAPHIC  DATA 

891215 

0.15 

AIRCRAFT  CHARACTERISTICS 

891215 

0.4 

AIRPORT  AND  AP  ASSET  STATUS 

891215 

0.11 

AIRSPACE  BOUNDARIES: 

891215 

6.1.0 

BULK  FLIGHT  PLAN  DATA 

891215 

0.16 

ESTABLISHED  ROUTES 

£91215 

0.2 

FLIGHT  PLANS 

0.21  INACTIVE  FPs 

0.22  ACTIVE  FPs 

0.23  TRIAL  FPs 

0.24  UP-ROUTE  ACTIVE  FPs 

891215 

^  0.13 

6E0GRAPHIC  DATA 

891215 

0.12 

6R0UND  OBSTACLES 

891215 

0.2! 

INACTIVE  FLIGHT  PLANS 

891216 

1  0.3 

METERABLE  FIX  COUNTS 

891216 

0.17 

NAVIGATION  AID  FIXES 

891215 

0.14 

RULES  AND  REGULATIONS 

ASSET  TEST  REQUIREMENTS 

891215 

0.5 

TRACK  HISTORY 

£91215 

0.23 

TRIAL  FLIGHT  PLANS 

891215 

C.s* 

UP-ROUTE  ACTIVE  FLIGHT  PLANS 

391216 

• 

S-APR-RO 
3  i  10 


*«  ALL  SATA  STORES  »« 
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Alternate  Naae 
ACTIVE  FLIGHT  PLANS 

AC  AND  ENVIRONMENT  DATA 


A1RCRAFT  CHARACTERISTICS 

AIRPORT  AND  AP  ASSET  STATUS 

AIRSPACE  BOUNDARIES 

SULK  FLIGHT  PLAN  DATA 

ESTABLISHED  ROUTES 

-I  is'ht  plans 

SEC GRAPH I C  DATA 


Lanq  Description 


The  ACTIVE  FLT  PLNS  database  contains  all  fliqht  plans  which  are 
currently  active  in  the  system.  Fliqht  plans  are  put  into  this 
database  by  7.0  FLIGHT  PLAN  OPERATION  SUPPORT  when  a  controller 
activates  a  fliqht  plan.  They  are  relieved  fro*  the  database  by  7.0  when 
a  controller  or  pilot  closes  a  fliqht  plan. 

The  Aircraft  and  Environaent  Database  provides  inforaation  required  by 
Area  Controllers,  as  well  as  several  DoD  AAS  ACF  functional  objects. 

This  database  provides  vital  inforiation  to  assist  in  aircraft 
identification  (AIRCRAFT  CHARACTERISTICS),  inforaation  to  assist  in 
the  processinq  of  fliqht  plans  '.ESTABLISHED  ROUTES,  NAV  AID  FIXES), 
inforeation  to  assist  in  surveillance  tarqet  presentation  (AIRSPACE 
BOUNDARIES,  GRUUND  OBSTACLES,  GEOSRAPHIC  BATA),  and  information  to 
assist  controllers  and  other  functional  objects  about  DoD  AAS  rules  and 
reputations  e.q  what  to  loq,  separation  rules,  etc.  This  data  is  all 
adaptable,  and  updated  by  OoD  AAS  Airway  Facilities. 

The  AIRCRAFT  CHARACTERISTICS  database  provides  controllers  and  DoD  AAS 
ACF  objects  with  aircraft  attributes.  This  information  is  used  in 
fliqht  plan  processinq,  aircraft  identification  and  tarqet  trackinq. 

The  AIRPORT  AND  AIRPORT  ASSET  STATUS  database  provides  Area  and 
National  Flow  Control  status  of  airport  facilities  and  their  assets. 

This  database  would  infora  controllers  of  any  airport  dosir.qs,  runway 
dosinqs,  status  of  facility  assets,  e.q.  inoperative  surveillance 
radars,  etc. 

The  AIRSPACE  BOUNDARIES  database  provides  DoD  AAS  ACF  objects  with 
airspace  toundary  assiqnnent  information.  This  database  is  adaptable, 
as  airspace  ccveraqe  requirements  chanqe.  This  database  is  employed  by 
the  display  systeas  of  Area  Control ,  and  by  surveillance  systems  as  a 
aechanisn  for  filtermq  tarqet  and  weather  nessaqes  outside  of  an 
area's  assigned  boundaries, 

This  database  is  used  to  store  bulk  fiiqh*  plans  until  X  am.  prior  to 
departure.  They  are  stored  here  by  6.1.3  BULrf  FLIGHT  pLAN  PRGC,  after 
the  Miqht  plan  has  oeen  svntax  and  qeocraohically  checked.  At  X  air, 
prior  tc  deoarture,  6.1.3  reaoves  the  plan  fros  the  database  and  sends 
it  to  7.0  FLIGHT  PLAN  OPERATION  SUPPORT  for  processinq. 

The  ESTABLISHED  ROUTES  database  orovices  aqreed-to  routes  aajor 
coaserciai  airline  carriers  will  follow. 

The  FLIGHT  PLANS  database  contains  fliqnt  plans  which  have  been  entered 
into  the  systes  throuqh  6.0A  FLIGHT  PLAN  ENTRY  SUPPORT  but  have  not  vet 
seen  activated,  Cannec  STEREO  fliqht  olans  are  also  stored  here. 

The  GEOGRAPHIC  DATA  database  provides  surveillance  systeas  and  Area 
Con-rcl  display  systems  with  qeooraphic  inforaation  and  landmarks, 
such  as  towers,  etc.  This  data  is  eaployed  in  surveillance  target 
-ilterinq  as  well  as  :n  inteqrete3  surveillance  view  processinq  of 
data  for  oresentatien  to  the  air  traffic  cor.treilsrs. 


IE:  26-APR-90 
13:10 
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\  Alternate  Naae 
IE  GROUND  OBSTACLES 


21  INACTIVE  FLIGHT  PLANS 


:  METEFABLE  FIX  COUNTS 
17  NAVIGATION  AID  FIXES 

:a  rules  and  regulations 


TRACT 


HISTORY 


33 


TRIAL  FLIGHT  PLANS 


Lonq  Description 


The  GROUND  OBSTACLES  database  provides  infcreation  about  aircraft 
hazards  within  the  TRACQN  boundaries  of  an  airport.  This  inforaation 
is  provided  for  display  processinq  by  the  inteqrated  surveillance 
inforaation  presentation  systea. 

Fliqht  Plans  which  have  been  syntax  checked,  qeoqrapnically  checked, 
route  checked,  and  which  have  trajectory  data  calculated.  These  plans 
are  for  fliqhts  which  have  not  yet  departed.  The  fliqht  plans  are  put 
into  the  database  by  6.0  FLIGHT  PLAN  ENTRY  SUPPORT  when  the  fliqht  plan 
is  filed,  They  are  resoved  froa  the  database  by  7.0  FLIGHT  PLAN 
OPERATION  SUPPORT  when  the  fliqht  plan  is  activated. 


The  NAVIGATION  AID  FIXES  database  provides  the  locations  for  all 
aircraft  naviqation  devices. 

The  RULES  AND  REGULATIONS  database  provides  air  traffic  controllers  anc 
DoD  AAS  ACF  objects  inforaation  on  air  traffic  control  rules  and 
reputations.  Such  inforaation  includes  tiniaua  separation,  loqqinq 
requireaents,  e:c. 

The  TRACK  HISTORY  database  is  laintenaned  by  TRAFFIC  SURVEILLANCE  and 
eaployed  by  AIRCRAFT  TRACK  MANAGEMENT  and  PREDICTION  and  RESOLUTION. 
Histones  of  tarqet  tracks  are  aaintained  to  identify  deviations  froa 
filed  fliqht  plans,  and  are  used  to  estiuate  potential  aircraft 
conflicts. 

This  dataoase  contains  trial  fliqht  plans.  They  are  entered  here  when 
6.0  FLIGHT  PLAN  ENTRY  SUPPORT  receives  a  request  to  process  a  trial 
fliqht  plan,  They  are  reaoved  fro*  this  catabase  whenever  an  aaenaaent 
fliqht  plan  which  watches  the  trial  fliqht  plan  is  received,  or  after 
the  trial  fliqht  plan  has  beer,  in  the  database  sore  than  X  sin, 


U°-RC'JTE  ACTIVE  FLIGHT  PLANS  This  database  contains  the  fliqht  plans  which  are  active  in  an  up-route 

area,  They  are  stored  here  when  an  up-route  area  sends  the  fliqht  olan 
to  this  area  for  an  extended  probe,  They  are  not  updated  f:e,  not 
syntax  checked,  etc.,  nor  are  trajectories  for  thes  saved).  They  are 
put  in  this  database  by  6.0  FLIGHT  PLAN  ENTRY  SUPPORT  when  it  receives 
the  extended  probe  request.  They  are  reaoved  froa  this  database  when 
6.0  receives  the  handoff  indicating  the  fliqht  is  now  in  this  area. 
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Appendix  B.  Appendix  B  -  Excelerator  Data  Dictionary  Disk 
Directory 

The  DoD  AAS  ACF  IOM  Excelerator  database  files  will  be  placed  on  the  STARS  repository.  This  data¬ 
base  is  named: 

•  DODACFDB.EXE  -  The  DoD  AAS  ACF  Excelerator  Database.  The  size  of  this  file  is  160,739  bytes. 

The  Excelerator  database  files  have  been  archived  using  the  PKWARE1  PKZIP  utility,  and  prepared  for 
automatic  self-extraction  using  the  MAKESFX,  PKSFX  and  ZIP2EXE  utilities.  None  of  these  utility  pro¬ 
grams  are  required  to  unpack  the  file. 

To  prepare  this  file  for  use  with  Excelerator,  you  must  do  the  following: 

1.  Upload  'DODACFDB.EXE'  to  an  IBM  PC  compatible  PC  running  DOS  3.0  or  higher; 

2.  Copy  this  file  to  your  hard  disk  or  high  density  floppy  disk; 

3.  Set  your  DOS  command  line  to  the  letter  of  the  disk  device  on  which  you  will  be  unpacking  the  file. 

For  example,  if  you  have  uploaded  the  file  and  have  copied  it  to  a  1.2  Megabyte  5  1/4'  floppy  disk  and 
plan  to  use  your  'A'  drive,  type  'A:'  at  the  DOS  command  line  and  press  the  enter  key; 

4.  At  the  DOS  command  line,  type  DODACFDB  and  press  the  enter  key; 

5.  Wait  until  the  unpacking  procedure  has  been  completed,  which  will  be  signified  by  the  printing  of  the  ' 
DOS  prompt  on  your  display.  After  the  unpacking  procedure  has  been  completed,  you  will  have  a  total 
of  72  files  on  your  disk; 

6.  Invoke  Excelerator  and  create  a  project  named  DOD  ACF 

7.  Import  the  database  into  the  DODACF  product  through  the  "XLD  INTERFACE'  utility 

8.  When  promped  for  the  Excelerator  file  name,  enter  A:\DODACF 


1  PKWARE,  Incorporated  is  a  developer  of  Shareware  application  software.  PKZIP(tm)  and  PKSFX(tm)  are  regis¬ 
tered  trademarks  of  PKWARE,  Incorporated.  None  of  PKWARE's  utility  software  is  transferred  in  a  form  usable 
by  another  user  upon  completion  of  the  elf-extracting  file  set  archive.  The  unarchiving  program  is  included  and 
cannot  be  separated  from  the  DODACFDB.EXE  executable  file. 
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Appendix  C.  Appendix  C  -  IOM  Methodology  Notes 
Presentation  Foils 

This  appendix  includes  the  IOM  Methodology  Notes  Presentation  foils  presented  at  the  QM15  Phase  II  final 
review,  describing  modeling  rules  we  learned  during  phase  II. 
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10M  METHODOLOGY  NOTES 

IQM15  TASK  OBJECTIVE 

•  LEARN*  THE  TECHNIQUES  USED  BY  FOXBORO  USED  IN  THE  SPECIFICA¬ 
TION  OF  SYSTEMS 

•  APPLY  FOXBORO'S  TECHNIQUES  TO  BUILD  A  SYSTEMS  SPECIFICA¬ 
TION  FOR  A  SELECTED  SYSTEM 

•  BUILD  AN  IOM  THAT  EXEMPLIFIES: 

-  OBJECT-ORIENTED  ORGANIZATION 
REUSABLE  ANALYSIS  PRODUCTS 
POSITIONING  FOR  SYSTEM  DESIGN  IN  Ada 
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WHAT  IS  AN  IOM? 

•  A  SPECIFICATION  FOR  A  SYSTEM  THAT  WAS  "CRAFTED".  USING 
FOXBORO'S  TECHNIQUES  OF  MODELING 

METHOD  OF  RAPIDLY  ACCUMULATING  AND  ASSIMILATING 
KNOWLEDGE 

METHOD  OF  MODELING  DATA  AND  CONTROL  MESSAGE  COM¬ 
MUNICATION  PATHS  BETWEEN  FUNCTIONAL  OBJECTS 

-  PEER  TO  PEER  COMMUNICATION 

-  PARENT  TO  CHILD  COMMUNICATION 

-  CHILD  TO  PARENT  COMMUNICATION 

METHOD  OF  ORGANIZING  FUNCTIONAL  OBJECTS,  BASED  ON 
THEIR  FUNCTIONAL  CAPABILITIES 


METHOD  OF  PRESENTATION  -  LAYERED  INFORMATION  PACK¬ 
AGING  APPROACH 
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WHAT  IS  A  FUNCTIONAL  OBJECT? 

•  A  FUNCTIONAL  OBJECT  IS  AN  OBJECT  THAT  PERFORMS  ONE  OR 
MORE  FUNCTIONS 

IT  HAS  STATE  ’ 

IT  HAS  INTERNAL  DATA 

IT  EXHIBITS  BEHAVIOR 

IT  HAS  OPERATIONS  THAT  BOTH  RECEIVE  AND  PASS  MESSAGES 
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EXAMPLE  OF  PROPER  IOM  FORM 

•  PRODUCTION  RATE  CONTROL  EXAMPLE 
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IOM  LAYERS  AND  MODELING  LEVELS 

•  CAPABILITY  IS  ASSIGNED  TO  EACH  FUNCTIONAL  OBJECT,  BASED  ON 
THE  LAYERED  MODEL 

•  MULTIPLE  LEVELS  CAN  EXIST  FOR  AN  IOM  LAYER  OF  CAPABILITY 

•  FUNCTIONAL  OBJECTS  AT  EACH  LEVEL: 

i 

PASS  DATA  AND  CONTROL  MESSAGES  TO  PEER  OBJECTS 
PASS  DATA  AND  CONTROL  MESSAGES  TO  PARENT  OBJECTS 
PASS-DATA  AND  CONTROL  MESSAGES  TO  CHILDREN  OBJECTS 

•  DIAGRAMS  ARE  PREPARED  FOR  EACH  LEVEL 
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WHITE  LAYERED  MODEL 

•  STRATEGIC  PLANNING  -  CORPORATE  (LAYER  5.0) 

•  MANAGEMENT  CONTROL  -  MIS  (LAYER  4.0) 

•  REAL  TIME  DECISION  SUPPORT  -  REAL  TIME  MANAGEMENT  (LAYER 
3.0) 

•  SUPERVISORY  CONTROL  (LAYER  2.0) 

•  ADAPTIVE  CONTROL  (LAYER  1.5) 

•  LOGIC  CONTROL  (LAYER  1.0) 

•  SENSOR  /  DEVICES  (LAYER  0.0) 
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IOM  MODELING  GUIDANCE 

•  FUNCTIONAL  OBJECTS  SHOULD  COMMUNICATE  WITH  EACH  OTHER 

•  THEY  SHOULD  TYPICALLY  POSSESS  TWO  OF  THE  THREE  CASES: 

PEER  TO  PEER  DATA  AND  CONTROL  MESSAGE  PASSING 
PARENT  TO  CHILD  DATA  AND  CONTROL  MESSAGE  PASSING 
CHILD  TO  PARENT  DATA  AND  CONTROL  MESSAGE  PASSING 
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IOM  MODELING  GUIDANCE  -  POSSIBLE  OBJECT 
COMMUNICATION  PROBLEMS 

•  OBJECTS  SHOULD  COMMUNICATE  WITH  LEVELS  DIRECTLY  ABOVE  OR 
BELOW  OR  WITH  PEER  OBJECTS 

•  IF  AN  OBJECT  BYPASSES  A  LEVEL.  COMMUNICATING  DIRECTLY  WITH 
A  GRANDPARENT  OBJECT.  A  MODELING  PROBLEM  MAY  EXIST 

•  IF  AN  OBJECT  COMMUNICATES  WITH  A  COUSIN  OBJECT,  A  MODELING 
PROBLEM  MAY  EXIST 


•  POSSIBLE  PROBLEMS: 

HOLLOW  BUBBLES 
IMPROPER  LEVELING 
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IOM  MODELING  GUIDANCE  -  NON-COMMUNICATING  PEERS 

•  OBJECTS  IN  A  GIVEN  LEVEL  SHOULD  HAVE  SOME  FORM  OF  COMMU¬ 
NICATION 

•  THIS  IS  NOT  A  HARD  AND  FAST  RULE,  BUT  SHOULD  BE  EXAMINED 

•  POSSIBLE  PROBLEMS 

IMPROPER  ALLOCATION  OF  FUNCTIONAL  OBJECTS  -  OBJECTS 
MAY  NEED  TO  BE  PROMOTED 
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IOM  MODELING  GUIDANCE  -  "HOLLOW  BUBBLES" 

•  GENERALLY,  IN  AN  IOM,  "HOLLOW  BUBBLES"  ARE  BAD 

"HOLLOW  BUBBLE"  IS  A  TERM  USED  FOR  PACKING  SEEMINGLY 
RELATED  PROCESSES  FOR  CONVENIENCE  OF  REPRESENTATION 

USED  HEAVILY  IN  STRUCTURED  ANALYSIS 


PROBLEMS: 

BREAKS  THE  IOM  RULE  THAT  ALL  OBJECTS  MUST  PERFORM 
WORK 

SERVES  ONLY,  AT  MOST  AS  A  DATA  AND  CONTROL  MESSAGE 
PASS-THRU 

CAN-  OBSCURE  THE  FACT  THAT  AN  ORGANIZATION  IS 
IMPROPER 
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Appendix  D.  Appendix  D  -  IOM  Diagram  Notation 


Transformation  Graphs 
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ATTACHMENT  A 


LIST  OF  REPORTS  SUBMITTED  TO  OTIC 


STARS  Technical  Plan  Analysis  (Final) 

Environment  Capability  Matrix 

Repository  Guidelines  and  Standards 

Foundation  Tools  Guidance  and  Education 

STARS  Structure  (DoD  AAS  IOM  Document  Version  1.3) 

Information  Object  Modeling  Methodology 

Software-First  Life  Cycle  Final  Definition 

Practical  Aspects  of  Repository  Operations 

Repository  Operations  and  Procedures 

Updated  Application  Blueprint  Definition  for  C3 

Repository  Guidebook  (Final)  Technical  Report 

Repository  Prototype  System  Specification 

SGML  Product  Review 

Technical  Report:  DTD  Creation 

Briefing  DTD  User's  Guide 

SGML  Lessons  Learned 

Sample  Tailoring  of  2167A  DIDS  for  Software-First  Life  Cycle 
General  Definition  of  Project  (Ada/SQL  Binding) 

User's  Manual  for  a  Prototype  Binding  of  ANSI-Standard  SQL 
to  Ada  Supporting  the  SAME  Methodology 


NOTE:  The  report  "Repository  Guidebook  (Final)  Technical  Report" 
includes  three  smaller  reports: 

IBM  STARS  Repository  Guidebook 
STARS  Repository  User's  Guide 
STARS  Reusability  Guidelines 
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Information  Object  Models  (IOM) 

This  section  provides  the  Information  Object  Models  for  the  major  functional  objects.  The  functional 
objects  presented  are: 

•  1.0  Traffic  Surveillance 

•  2.0  Weather  Surveillance 

•  3.0  Prediction  and  Resolution 

•  5.0  Aircraft  and  Track  Management 

•  6.0  Flight  Plan  Entry  Support 

•  7.0  Flight  Plan  Operation  Support 

•  8.0  Area  Control 

•  4.0  Recording  Support. 

Functional  objects  8.0  Area  Control  and  4.0  Recording  Support  are  included,  but  are  not  complete.  Per¬ 
sonnel  assigned  to  complete  these  objects  were  released  by  management,  before  they  could  complete  their 
required  documentation  assignments.  ' 
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Figure  14.  1.1  RADAR  SUPERVISOR.  This  figure  illustrates  RADAR  SUPERVISOR  and  its  children  objects, 
1.1.1  RADAR  COUNTING,  1.1.2  RADAR  REPORT  FILTER,  1.1.3  ECM  DETECTOR,  1.1.4 
NON-TARGET  DATA  PROCESSING. 
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Figure  15.  1.1  RADAR  SUPERVISOR  BEHAVIOR.  This  figure  illustrates  the  state  transition  diagram  for 
changing  between  three  states,  namely;  RADAR  ONLINE,  RADAR  INVALID,  and  RADAR 
OFFLINE. 
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Figure  8.  DoD  AAS  Area  Control  Facility.  This  figure  illustrates  the  major  functional  objects  of  the  DoD  AAS  Area 
Control  System.  The  figure  also  illustrates  the  information  flows  between  these  objects. 


